+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., >
