CiviCRM Community Forums (archive)

Plan B: we remove version as a mandatory field and default to version 3 we keep civicrm_api, CRM.api and {crmAPI} as v3 only and if/when api 4 is there, we introduce civicrm_api4 CRM.api4 and crmAPI4 at that time?

+1 on this. It's more writable/readable for API-consumers.

Talked a little more about this with Eileen on IRC. I lean softly in favor of throwing an exception in the civicrm_api3 -- but with a few questions/thoughts:

a) I'm a little nervous that we have too many possible entry points for PHP developers ("function civicrm_api", "function civicrm_api3", "class civicrm_api3"). How can we update the documentation to make the distinction intuitive? (Aside: it's a little counter-intuitive that the procedural facade will use exceptions while the OOP facade won't, but... it's still good to make incremental progress...)

b) It's not going to be feasible (with APIv3 / Civi 4.x) for civicrm_api3() to throw exceptions with meaningful class names (e.g. CRM_API_MissingArgumentException) -- it would need to throw some generic exception class (like "API_Exception", "CRM_Core_Exception", etc). The exception class will be part of the public interface, so it should be something that we're comfortable supporting in future versions. Are we comfortable with something like "CiviCRM_API3_Exception" or "civicrm_api3_Exception" or "CRM_API_APIv3Exception"?