cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] RESTful API for CloudStack agents
Date Tue, 02 Apr 2013 19:33:30 GMT
On Tue, Apr 02, 2013 at 03:14:46PM -0400, Sebastien Goasguen wrote:
> 
> On Apr 2, 2013, at 3:00 PM, Donal Lafferty <donal.lafferty@citrix.com> wrote:
> 
> > Could I get some feedback on the following strategy for mapping CloudStack RPC commands
to HTTP requests?
> > 
> > The general approach is to:
> > 1. map each category of command to a URL.  Each category corresponds roughly to
a resource type being manipulated.
> > E.g. /cloudstack/latest/storagepool/
> > 2. make the command itself a path under the category
> > E.g. /cloudstack/latest/storagepool/create
> > 3. make resource changes using a POST request with parameters JSON encoded in the
body
> > E.g.
> > 
> > POST /cloudstack/latest/storagepool/{create | modify | destroy}
> > POST /cloudstack/latest/volumes/{create | destroy}
> > POST /cloudstack/latest/vm/{start | stop}
> > 4. query resource state using a GET request that identifies specific resources with
a query parameter
> > E.g. GET /cloudstack/latest/vm?id=1&id=2&id=3
> > 
> > 
> 
> I just read something about it the other day, and it seems people are starting to use
PATCH to update .
> 
> So POST would be to create, PATCH to update, GET to list….
> 
> so everything fits under /cloudstack/storagepool/ no need for a /create...

Not to be considered too much of a REST-afarian, consider the difference
in meaning between a PUT and PATCH.

PUT should be used to replace the resource in question with the contents
provided in the request. [1]

PATCH should be used when "patching" (or partially modifying) the resource in
question. [2]

-chip

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
[2] http://tools.ietf.org/html/rfc5789

Mime
View raw message