Dale Worley wrote: > Reading another REST message leads me to summarize: > > GET is for inquiries, which do not change the state > PUT is for changing an *existing* resource > POST is for generating a *new* resource that is subordinate (in some > way) to an *existing* resource > > Dale > >
PUT is also about creating the resource which identifier you know a priori (that's the most important distinction brought up in [1]). There are many examples of such usage among existing REST APIs (Apache S3 API is using PUT in this way). Personally I think that the most important difference (and Scott brought it up already) is not between creating and updating but between idempotent and not idempotent behavior (if after PUT, PUT, PUT you end up with a single resource you are using PUT correctly, if you have up to 3 new resources - you should have used POST). And yeah: that probably means that sipXconfig should have used POST (a mistake that new sipXcallcontroller can easily fix as Dale described before). POST is (sometimes unjustifiably) shunned in REST APIs because it can be easily overused and one of the goals of resource oriented API is introduce as many resources as you need instead of introducing as many operations as you need (which is a SOAP approach). One generally accepted use of POST (in addition to creating new resources) is to tunnel PUTs and DELETEs that some clients (such as Zimbra) cannot generate. D. [1] RESTful Web Services, Richardson and Ruby, O'Reilly http://oreilly.com/catalog/9780596529260 _______________________________________________ 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/
