API team minutes
1) versioning - versioning will be implemented via $params['version'] = '3' (for example). Code include will always refer to CiviCRM/Api/APIFile and relevant version will be called depending on $Param.
For now version 2 will be default if no version is selected. For API the default will be set on login and the version param will override the API
Multiple versions may be implemented @ once as we will not get all code to v4 straight away
v3 APIs
= take and array in & rtn an array
= use correct verbs
v4
= fly
= make coffee
= are really cool & clever
Old APIs will still ship & work (limited testing) but support requests will not be tolerated (as version upgrade should be trivial). If they break focus will be on notifying people rather than fixing
2) tag API is # 1 priority - get this to be a 'perfect' v4 API as an example
3) Fields - we will ask Lobo what the prefered standard for param values from XML schema. Either:
"If Uniquename exists then uniquename otherwise Name"
OR
"Name"
Currently GET requests sometimes return uniquename even though documentation usually refers to name. Presumably uniquenames are there for a reason and the most future proofed option for v4 is to support them where they exist. (Note that both may work but only one variant per above should be supported)
4) Documentation - @schema
@schema is really cool for now - later let's add more e.g. participant_id on contribute (BAO level) / 'special fields' later
5) API team need to focus on
- implementing versioning system
- getting model v4 API really good (tag) so we can copy it
- making it easy for others to contribute
6) Future wish list
- warnings mode - a param that can be set to be 'strict' error messages e.g about deprecated functions while developing
- enhanced version of schema module
7) pledge API - Eileen realised the hold up to getting it into core as V2 was documentation. Not focussing on bringing it to v3 standards as less productive than 'simpler' APIs at this stage
8) Salicious rumours shared. People slandered. Fun had.
9) Hopefully coding will start early next year as not much time this side of Xmas

3 Comments
Hide/Show CommentsNov 18, 2010
David Greenberg
Exciting to see decisions made / direction set for this important work. Kudos to Eileen and the "API Team" for driving this forward.
Nov 19, 2010
Donald A. Lobo
A few thoughts:
1. Having multiple versions at the same time is a support and security issue (need to change code in multiple places). That said I do understand the need for it. However I would vote strongly against more than 2 versions active at the same time. Would also like to see the older version deprecated in a max of 2 releases. With the above, i would put v3 and v4 together and do a complete job with v3
2. We should use unique name in all cases. Much easier and makes things more consistent
3. Would be great to get a list of things we will do in 3.4 / 4.0. For planning purposes, assume that the alpha release is coming out in January
Dec 08, 2010
Piotr Szotkowski
just a quick comment – I’d rather the versioning variable was
api_version, for the potential future situation whereversionmakes sense as one of the resource fields for some resource.