incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Date Mon, 25 Feb 2013 02:10:42 GMT
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.chen@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" <aemneina@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 <tsp@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 <jburwell@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.,
>>>
>

Mime
View raw message