You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Rohit Yadav <bh...@apache.org> on 2013/01/30 20:14:36 UTC
[PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
I want to propose that we deprecated the current non-RESTful APIs and
api server over next few months, year, 2 years... (let's vote on the
timeline, what do you think should be duration for maintaining old set
of apis?). And, we work on a maintainable REST-ful api server using
JAX-RS (suggest any other technology)?
Issues:
https://issues.apache.org/jira/browse/CLOUDSTACK-638
https://issues.apache.org/jira/browse/CLOUDSTACK-1093
Regards.
Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by Rohit Yadav <bh...@apache.org>.
On Thu, Jan 31, 2013 at 5:28 AM, Prasanna Santhanam <ts...@apache.org> wrote:
> On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
>> I want to propose that we deprecated the current non-RESTful APIs and
>> api server over next few months, year, 2 years... (let's vote on the
>> timeline, what do you think should be duration for maintaining old set
>> of apis?). And, we work on a maintainable REST-ful api server using
>> JAX-RS (suggest any other technology)?
>>
>> Issues:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-638
>> https://issues.apache.org/jira/browse/CLOUDSTACK-1093
>
> +1
>
> a) Will both methods query and REST be supported via different
> endpoints while the deprecation is happening?
We should keep the same parent endpoint, like host:port/client/api or /api.
>
> b) Is the plan to reuse existing API entities, which surface to a
> query endpoint naturally over a REST endpoint, or do you plan to
> re-write the API entities?
I've some ideas, but I'll try to research possible ways of doing that,
present them and maybe a POC to our community for feedback, flames and
suggestions before I start working on it.
>
> For eg: CreateEntity, DeleteEntity, ListEntity over
>
> @Http(method=GET)Entity.list(), @Http(method=POST/PUT)Entity.create(), @Http(method=DELETE)Entity.delete()
>
> c) An alert to downstream projects may be when you start this? -
> jclouds, libcloud etc
Sure.
>
>
> --
> Prasanna.,
RE: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by Alex Huang <Al...@citrix.com>.
+1
--Alex
> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com]
> Sent: Thursday, January 31, 2013 10:45 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: cloudstack-users@incubator.apache.org
> Subject: Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
>
> 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).
>
> 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
>
> On Jan 31, 2013, at 8:28 AM, Prasanna Santhanam <ts...@apache.org> wrote:
>
> > On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
> >> I want to propose that we deprecated the current non-RESTful APIs and
> >> api server over next few months, year, 2 years... (let's vote on the
> >> timeline, what do you think should be duration for maintaining old set
> >> of apis?). And, we work on a maintainable REST-ful api server using
> >> JAX-RS (suggest any other technology)?
> >>
> >> Issues:
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-638
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-1093
> >
> > +1
> >
> > a) Will both methods query and REST be supported via different
> > endpoints while the deprecation is happening?
> >
> > b) Is the plan to reuse existing API entities, which surface to a
> > query endpoint naturally over a REST endpoint, or do you plan to
> > re-write the API entities?
> >
> > For eg: CreateEntity, DeleteEntity, ListEntity over
> >
> > @Http(method=GET)Entity.list(),
> @Http(method=POST/PUT)Entity.create(),
> @Http(method=DELETE)Entity.delete()
> >
> > c) An alert to downstream projects may be when you start this? -
> > jclouds, libcloud etc
> >
> >
> > --
> > Prasanna.,
Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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.,
>
Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by 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
Posted by Rohit Yadav <bh...@apache.org>.
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.
Regards.
> 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
>
> On Jan 31, 2013, at 8:28 AM, Prasanna Santhanam <ts...@apache.org> wrote:
>
>> On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
>>> I want to propose that we deprecated the current non-RESTful APIs and
>>> api server over next few months, year, 2 years... (let's vote on the
>>> timeline, what do you think should be duration for maintaining old set
>>> of apis?). And, we work on a maintainable REST-ful api server using
>>> JAX-RS (suggest any other technology)?
>>>
>>> Issues:
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-638
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-1093
>>
>> +1
>>
>> a) Will both methods query and REST be supported via different
>> endpoints while the deprecation is happening?
>>
>> b) Is the plan to reuse existing API entities, which surface to a
>> query endpoint naturally over a REST endpoint, or do you plan to
>> re-write the API entities?
>>
>> For eg: CreateEntity, DeleteEntity, ListEntity over
>>
>> @Http(method=GET)Entity.list(), @Http(method=POST/PUT)Entity.create(), @Http(method=DELETE)Entity.delete()
>>
>> c) An alert to downstream projects may be when you start this? -
>> jclouds, libcloud etc
>>
>>
>> --
>> Prasanna.,
>
RE: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by Alex Huang <Al...@citrix.com>.
+1
--Alex
> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com]
> Sent: Thursday, January 31, 2013 10:45 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: cloudstack-users@incubator.apache.org
> Subject: Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
>
> 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).
>
> 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
>
> On Jan 31, 2013, at 8:28 AM, Prasanna Santhanam <ts...@apache.org> wrote:
>
> > On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
> >> I want to propose that we deprecated the current non-RESTful APIs and
> >> api server over next few months, year, 2 years... (let's vote on the
> >> timeline, what do you think should be duration for maintaining old set
> >> of apis?). And, we work on a maintainable REST-ful api server using
> >> JAX-RS (suggest any other technology)?
> >>
> >> Issues:
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-638
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-1093
> >
> > +1
> >
> > a) Will both methods query and REST be supported via different
> > endpoints while the deprecation is happening?
> >
> > b) Is the plan to reuse existing API entities, which surface to a
> > query endpoint naturally over a REST endpoint, or do you plan to
> > re-write the API entities?
> >
> > For eg: CreateEntity, DeleteEntity, ListEntity over
> >
> > @Http(method=GET)Entity.list(),
> @Http(method=POST/PUT)Entity.create(),
> @Http(method=DELETE)Entity.delete()
> >
> > c) An alert to downstream projects may be when you start this? -
> > jclouds, libcloud etc
> >
> >
> > --
> > Prasanna.,
Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by John Burwell <jb...@basho.com>.
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).
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
On Jan 31, 2013, at 8:28 AM, Prasanna Santhanam <ts...@apache.org> wrote:
> On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
>> I want to propose that we deprecated the current non-RESTful APIs and
>> api server over next few months, year, 2 years... (let's vote on the
>> timeline, what do you think should be duration for maintaining old set
>> of apis?). And, we work on a maintainable REST-ful api server using
>> JAX-RS (suggest any other technology)?
>>
>> Issues:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-638
>> https://issues.apache.org/jira/browse/CLOUDSTACK-1093
>
> +1
>
> a) Will both methods query and REST be supported via different
> endpoints while the deprecation is happening?
>
> b) Is the plan to reuse existing API entities, which surface to a
> query endpoint naturally over a REST endpoint, or do you plan to
> re-write the API entities?
>
> For eg: CreateEntity, DeleteEntity, ListEntity over
>
> @Http(method=GET)Entity.list(), @Http(method=POST/PUT)Entity.create(), @Http(method=DELETE)Entity.delete()
>
> c) An alert to downstream projects may be when you start this? -
> jclouds, libcloud etc
>
>
> --
> Prasanna.,
Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by Rohit Yadav <bh...@apache.org>.
On Thu, Jan 31, 2013 at 5:28 AM, Prasanna Santhanam <ts...@apache.org> wrote:
> On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
>> I want to propose that we deprecated the current non-RESTful APIs and
>> api server over next few months, year, 2 years... (let's vote on the
>> timeline, what do you think should be duration for maintaining old set
>> of apis?). And, we work on a maintainable REST-ful api server using
>> JAX-RS (suggest any other technology)?
>>
>> Issues:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-638
>> https://issues.apache.org/jira/browse/CLOUDSTACK-1093
>
> +1
>
> a) Will both methods query and REST be supported via different
> endpoints while the deprecation is happening?
We should keep the same parent endpoint, like host:port/client/api or /api.
>
> b) Is the plan to reuse existing API entities, which surface to a
> query endpoint naturally over a REST endpoint, or do you plan to
> re-write the API entities?
I've some ideas, but I'll try to research possible ways of doing that,
present them and maybe a POC to our community for feedback, flames and
suggestions before I start working on it.
>
> For eg: CreateEntity, DeleteEntity, ListEntity over
>
> @Http(method=GET)Entity.list(), @Http(method=POST/PUT)Entity.create(), @Http(method=DELETE)Entity.delete()
>
> c) An alert to downstream projects may be when you start this? -
> jclouds, libcloud etc
Sure.
>
>
> --
> Prasanna.,
Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by John Burwell <jb...@basho.com>.
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).
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
On Jan 31, 2013, at 8:28 AM, Prasanna Santhanam <ts...@apache.org> wrote:
> On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
>> I want to propose that we deprecated the current non-RESTful APIs and
>> api server over next few months, year, 2 years... (let's vote on the
>> timeline, what do you think should be duration for maintaining old set
>> of apis?). And, we work on a maintainable REST-ful api server using
>> JAX-RS (suggest any other technology)?
>>
>> Issues:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-638
>> https://issues.apache.org/jira/browse/CLOUDSTACK-1093
>
> +1
>
> a) Will both methods query and REST be supported via different
> endpoints while the deprecation is happening?
>
> b) Is the plan to reuse existing API entities, which surface to a
> query endpoint naturally over a REST endpoint, or do you plan to
> re-write the API entities?
>
> For eg: CreateEntity, DeleteEntity, ListEntity over
>
> @Http(method=GET)Entity.list(), @Http(method=POST/PUT)Entity.create(), @Http(method=DELETE)Entity.delete()
>
> c) An alert to downstream projects may be when you start this? -
> jclouds, libcloud etc
>
>
> --
> Prasanna.,
Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by Prasanna Santhanam <ts...@apache.org>.
On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
> I want to propose that we deprecated the current non-RESTful APIs and
> api server over next few months, year, 2 years... (let's vote on the
> timeline, what do you think should be duration for maintaining old set
> of apis?). And, we work on a maintainable REST-ful api server using
> JAX-RS (suggest any other technology)?
>
> Issues:
> https://issues.apache.org/jira/browse/CLOUDSTACK-638
> https://issues.apache.org/jira/browse/CLOUDSTACK-1093
+1
a) Will both methods query and REST be supported via different
endpoints while the deprecation is happening?
b) Is the plan to reuse existing API entities, which surface to a
query endpoint naturally over a REST endpoint, or do you plan to
re-write the API entities?
For eg: CreateEntity, DeleteEntity, ListEntity over
@Http(method=GET)Entity.list(), @Http(method=POST/PUT)Entity.create(), @Http(method=DELETE)Entity.delete()
c) An alert to downstream projects may be when you start this? -
jclouds, libcloud etc
--
Prasanna.,
Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Posted by Prasanna Santhanam <ts...@apache.org>.
On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
> I want to propose that we deprecated the current non-RESTful APIs and
> api server over next few months, year, 2 years... (let's vote on the
> timeline, what do you think should be duration for maintaining old set
> of apis?). And, we work on a maintainable REST-ful api server using
> JAX-RS (suggest any other technology)?
>
> Issues:
> https://issues.apache.org/jira/browse/CLOUDSTACK-638
> https://issues.apache.org/jira/browse/CLOUDSTACK-1093
+1
a) Will both methods query and REST be supported via different
endpoints while the deprecation is happening?
b) Is the plan to reuse existing API entities, which surface to a
query endpoint naturally over a REST endpoint, or do you plan to
re-write the API entities?
For eg: CreateEntity, DeleteEntity, ListEntity over
@Http(method=GET)Entity.list(), @Http(method=POST/PUT)Entity.create(), @Http(method=DELETE)Entity.delete()
c) An alert to downstream projects may be when you start this? -
jclouds, libcloud etc
--
Prasanna.,