cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <min.c...@citrix.com>
Subject Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Date Mon, 25 Feb 2013 17:18:54 GMT
Thanks for the interest in this topic. Here is a WIP FS:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/REST+API+Server+Arch
itecture. The real work has not been started yet. Feedback and suggestions
are welcome.

-min

On 2/25/13 8:36 AM, "John Burwell" <jburwell@basho.com> wrote:

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