Author Topic: REST v3 (Read 2553 times)

xavier · November 19, 2008, 12:06:41 am

Hi,

Given the various improvements suggestions, and identified incoherent points in the existing interface, I think we should consider not maintaining compatibility but go for a new version.

Some of the discussions (around the authentication and keys for instance) could, and should be added on the existing interface, some others (eg having a coherent and systematic naming of the actions, always use id, the proper method...) are going to be difficult to fit within the existing one.

Keeping in mind the timing (Feature freeze in about 2 weeks), I don't think we'll have the v3 ready to ship. Please correct me if I'm wrong. What of what has been discussed could/should be developed for the next version ?

X+

acrosman · November 22, 2008, 10:21:19 am

I definitely think that most of what has been discussed should get pushed into a new version. We could go with everything, and just start with a clean page, instead of trying to slip things in over the next couple days. I just asked Lobo about the table changes I'd need to do the authentication function, I can get it done, but it would probably a rush. Maybe waiting on even that detail would be best.

So things that seem to be emerging from various fronts:

Handling authentication better so that different server-to-server connections can have a set key, while others can use the session.
Adding support for all more rest verbs, certainly POST perhaps PUT and DELETE.
Adding more functions that are accessible to the API.

How many of the Rail suggestions do we think are important to honor? Do we want to make the task easy from Rails or are things that we don't want to support:

Represent objects as XML
Always use XML nodes that have names that either represent what type of object they are (like <contact> ) or have a type attribute (like <ResultSet type="array"> )
Use ID fields named "id" for every class of object
Give unique URLs to each object, by ID, like: http://servername/contacts/1
Respond differently to each of the HTTP protocol's methods: GET, POST, PUT, DELETE
Accept raw XML in the POST body of a HTTP request (not in the traditional application/x-www-form-urlencoded style)
Use the HTTP "Status" header to denote errors
Report the URL of a newly created object in the HTTP "Location" header

Lobo, do any plans exist to extend the API itself to cover more functions of CiviCRM?

Aaron

Donald Lobo · November 23, 2008, 06:52:06 am

a couple of things:

1. No plans to extend the API for other function in 2.2. If folks report something missing for a core object/component, we'll investigate and potentially add it.

2. We'd be willing to push the api code freeze to dec 15

if we can get more things done and the api improved etc

(including unit tests for all new functionality)

3. I think some of the rails ideas are good and worth implementing. Initally i would find and fix all the places that the api is inconsistent. I'd also use POST operations for ADD/EDIT and potentially DELETE operations for DELETE. I dont think the rails folks have filed an issue on this as yet, i'll re-ping them. Given that, some things we might weant to consider include:
(unique urls to each object, http status header to denote error, url of newly created object in location header)

lobo

acrosman · November 23, 2008, 01:58:33 pm

Is there a good explanation of how unit tests are currently setup for the project? I'm happy to add/edit them, but I'm not sure where to start.

CiviCRM Community Forums (archive)

News:

Author Topic: REST v3 (Read 2553 times)

xavier

REST v3

acrosman

Re: REST v3

Donald Lobo

Re: REST v3

acrosman

Re: REST v3