On Tue, Apr 02, 2013 at 03:14:46PM -0400, Sebastien Goasguen wrote:
>
> On Apr 2, 2013, at 3:00 PM, Donal Lafferty <donal.laffe...@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
