CiviCRM Community Forums (archive)

What's broken ? A 1000char long line is a bit hard to read

(btw, adding a debug=1 that would add \n might be a something to add in the sprint

hi,

debug might not be the right  name. nice=1? the only thing was to get the json formatted, not to display more info

encoding problem, < > somewhere in the data is a common issue, as is accentuated chars.

Try wget the page, will be easier to analyse.

X+

Hi,

Just flagging that Lobo suggested I try to refine our discussions into a standard for the API. I have been trying to write it onto the Wiki

http://wiki.civicrm.org/confluence/display/CRM/API+Conventions.

What I have written may not be entirely correct but you can hash it into something that you think is correct over a warm beer

Yeah - so the bit that I'm trying to do now is the 'gap analysis - just noting down things I know of that need attention.

One thing that I can't quite figure out is what value 'update' functions add. To me an add function that will update is an ID is passed is more useful. Update to me makes sense potentially where the values passed in are NOT the id - ie. if you pass in first_name & last_name and it is a dedupe match which matches EXACTLY one contact (or similar for phone number, address bassed on location_type & phone_type) then it gets updated otherwise error=1 & error_message="x records match your query"

I'm not anti-update ... as long as create does the same thing - the contact api currently has add, update & create. Add is deprecated but it allows you pass in an array and if contact_id is part of that array it adds otherwise it updates - create doesn't do this - making it much less useful to me

I agree with you, creating a create and update would mean more work for me too. But I think that if I were new to this, I would expect a CRUD set of API's? So in that situation I would be confused by having an add to create and update, and I would be comforted by seeing create and update as separate things.