CiviCRM Community Forums (archive)

In the long run I agree that we should move to a better breakdown of the commands and the methods.  When I extended the old experimental/proof of concept REST interface, I just wanted to find a way to expose the whole CiviCRM API to the interface.  At the time there was a small selection of functions exposed, and I needed to develop a better way to check for the function.  I'm certainly not going to defend this as the best way to get the job done.

You raised two issues that I am also worried about.  First, how do we do this without maintain a list of all the functions, and second do we do this in v2 or v3.

From a quick review of the API methods the naming is pretty consistent, each section has a subset of: add, get, search, delete, and remove, commands (there might be a couple more, but at any rate the list appears to be fairly short).  We could map those to the request methods: get/search -> GET, add -> POST etc.  It doesn't look like it would be too onerous.  I'd be inclined to leave a catch-all that defaulted predictably in case new commands get added that introduce a new word.

As for versions, I think I'd like to see v2 continue to support everything coming in over GET even if we declare some of those commands depreciated for v3.  We could start to allow some commands to come in by other methods, but I'd like to see the support of all GET continue for a little while longer.

Do we want to use methods other than GET and POST?  Should we also allow PUT and DELETE?  My understanding (which is limited) is that Apache often needs additional configuration to make PUT and DELETE work properly for REST interfaces.  Is that added a burden that some configurations wont be able to overcome because of their hosting environments?

Aaron

Well right now the tag ajax thingie doesn't use post, only get. I'll check if we can make the rest accepts both post and get and try to use post for the destructive methods.

My guess right now is the REST interface only accepts GET requests (that's certainly all I've ever tested).  It would be simple enough to get the parameters handled correctly, the hard part will be picking which commands have to come over which methods.  As I said before that shouldn't be TOO bad.

What really needs to happen is we need to get moving on some actual code to get things to Lobo before the code freeze goes into effect.

We need the new authentication method written, and adding on the ability for at least some commands to come in over POST requests.

Aaron

For more suggestions see the new thread at:
http://forum.civicrm.org/index.php?topic=5644

Granted that looks like a whole new set of suggestions that need to be considered. 

Interesting post.

Not sure about the DELETE/PUT methods, it looks like the right http things to do, but I'm not aware of any javascript/ajax library that can handle them, at least easily.

I think that if having POST + $_post['action'] is allowing the rest interface to be called both from another server and from a js interface, that is better (from a practical point of view, not a theorical one).

X+

You can do PUT and DELETE in Javascript:
http://www.wynia.org/wordpress/2007/03/18/not-just-get-and-post-http-put-and-delete-with-javascript/
It's just not something people talk about a whole lot.

My only concern about adding the other two verbs is making sure we're not causing a problem for server support.  I've read mixed things about default configurations on Apache (I haven't read anything about other servers), which I suspect means we'll need to make sure there are directions that make it clear what to check for in their server's configuration.

If everyone is clear it's not an issue at that level, I don't really see a problem with it.

Aaron

That sounds like a good compromise to me.