cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <jburw...@basho.com>
Subject Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Date Mon, 25 Feb 2013 16:36:40 GMT
+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 <bhaisaab@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.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