Currently I am working on redesigning a brand new REST compliant api server. Will share the architecture design with the community when the document is ready, then everybody can chip in to provide feedback on the new proposal.
Thanks -min On 1/31/13 9:46 PM, "Ahmad Emneina" <aemne...@gmail.com> wrote: >+1 on deprecation while bringing in the new. Does this avert the need for >a >major version increment, or is this a big enough feature to warrant the >big >five oh? > > >On Thu, Jan 31, 2013 at 9:36 PM, Prasanna Santhanam <t...@apache.org> >wrote: > >> On Fri, Feb 01, 2013 at 01:35:58AM +0530, Rohit Yadav wrote: >> > On Thu, Jan 31, 2013 at 10:44 AM, John Burwell <jburw...@basho.com> >> wrote: >> > > All, >> > > >> > > I hate to be the pedantic REST guy, but I think there is a >> > > different worth noting between PUT and POST. POST [1] should be >> > > used for operations where the server will provide the identity of >> > > the resource where PUT [2] is intended for operations where the >> > > client will provide the identity of the resource. While I know it >> > > has become common practice to combine these two methods, I think >> > > that it weakens the API intent and contract. In the CloudStack >> > > model, it seems to me that POST operations would create resources >> > > (e.g. a new VM definition) where the server will return the >> > > resource's identity (e.g. a UUID) as part of the response. A PUT >> > > operation would mutate an existing resource (e.g. change the >> > > definition of a VM identified by a particular UUID). >> > > >> > >> > I hear you and if we'll do it, we'll do it the right way this time. >> > >> >> +1 - good to know the POST/PUT difference >> >> > >> > > Thanks, >> > > -John >> > > >> > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 >> > > [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 >> > > >> -- >> Prasanna., >>
