+1 as well regarding sharing earlier rather than later. Would it be possible to publish the work in progress design to the wiki for wider community visibility?
On Feb 24, 2013, at 9:10 PM, Rohit Yadav <bhais...@apache.org> wrote: > Hi Min, can you share your plans on this one so I can fix api > discovery and cloudmonkey. As CloudStack's release timelines would > increase, I want to fix the api discovery in cloudmonkey such that > it's maintainable and adapts to changes withing api servers (the old > one, new rest one and cloud-engine). > > Regards. > > On Fri, Feb 1, 2013 at 10:57 PM, Min Chen <min.c...@citrix.com> wrote: >> 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., >>>> >>
