On Thu, 2009-08-13 at 12:25 -0400, Damian Krzeminski wrote: > Xingjun Chu wrote: > > Hi , > > > > > > > > I am using REST API click to call for some integration work and got an > > issue with it. Since some web proxy doesn't support "PUT", some of my > > work doesn't work. > > > > > > > > So just wondering why uses "PUT" for the REST API other than for example > > "GET", what's the design intent? > > > > PUT makes more semantic sense (you are "setting" the call instance). > > > > > > > > Also when using "PUT", some web server expects content length > 0, so > > everytime I have to put some "dummy" in the content to make web server > > happy. > > > > Yes. That's a restlet issue... > > > > > > > I would like to suggest to use "GET", but no sure what's the consequence. > > > > sipXconfig (via restlet) also supports POST tunneling for those clients and > proxies that cannot issue anything but GET and POST... > > http://www.restlet.org/documentation/1.0/api/org/restlet/service/TunnelService.html > > It would look something like: > > POST > https://{user}:{passwo...@{host}:8443/sipxconfig/rest/call/{number}?methodParameter=PUT > > That said - since GET is not used for anything useful, I can change it so > that GET and PUT do the same thing.
Properly speaking, GET should only be used when doing so is idempotent and should have no effect on server state. A client or proxy should be able to assume that a GET request can be repeated without user involvement because of this. A POST is exactly the opposite - it is defined to assume that it does have server side state effects and so cannot be repeated without confirmation (this is the source of those warnings you sometimes get from the browsers about 'do you really want to submit this form again'). So a RESTful API that is just retrieving information (lookup in a phonebook) should be a GET, but one that is triggering an action on the server that might not be correct to do twice (making a call) should use POST. PUT is properly used when you're replacing or creating a resource on the server - I can't think of an example of when it would be the right choice in any of our current applications. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
