cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <>
Subject Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack apis and api server
Date Thu, 31 Jan 2013 18:44:50 GMT

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



On Jan 31, 2013, at 8:28 AM, Prasanna Santhanam <> 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:
> +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.,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message