Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server

[Prasanna Santhanam <ts...@apache.org>]

On Fri, Feb 01, 2013 at 01:35:58AM +0530, Rohit Yadav wrote:
> On Thu, Jan 31, 2013 at 10:44 AM, John Burwell <jb...@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.,

Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server

[Chip Childers <ch...@sungard.com>]

On Mon, Feb 25, 2013 at 07:40:42AM +0530, Rohit Yadav 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).

+1 to wanting to hear more about this.

Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server

[Min Chen <mi...@citrix.com>]

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" <jb...@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 <bh...@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 <mi...@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" <ae...@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 <ts...@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 <jb...@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.,
>>>>> 
>>> 
>

Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server

[John Burwell <jb...@basho.com>]

+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 <bh...@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 <mi...@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" <ae...@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 <ts...@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 <jb...@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.,
>>>> 
>> 

Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server

[Rohit Yadav <bh...@apache.org>]

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 <mi...@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" <ae...@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 <ts...@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 <jb...@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.,
>>>
>

Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server

[Min Chen <mi...@citrix.com>]

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" <ae...@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 <ts...@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 <jb...@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.,
>>

Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server

[Ahmad Emneina <ae...@gmail.com>]

+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 <ts...@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 <jb...@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.,
>