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