[occi-wg] Semantics of OCCI API: nouns and verbs

eprparadocs at gmail.com eprparadocs at gmail.com
Thu Apr 16 12:07:13 CDT 2009


Once again I am beginning to wonder if we are getting too lost in the
forest. This is clearly a protocol issue and as such we should be
supporting multiple ways.

I prefer a simple XML rendering (and Atom seems way too heavy) for all
the requests. That includes putting in things like set, destroy,etc. The
protocol step should be to map the definitions into something bitsy!

Chuck Wegrzyn

Sam Johnston wrote:
> On Thu, Apr 16, 2009 at 3:05 PM, Richard Davies
> <richard.davies at elastichosts.com
> <mailto:richard.davies at elastichosts.com>> wrote:
> 
> 
>     Agreed in principle, but there's an implementation issue that many
>     common
>     HTTP libraries will only do POST/GET, not PUT/DELETE, so need url
>     versions
>     of 'UD' anyway.
> 
> 
> Wow, you guys have really thought about it :) This problem more
> manifests itself in enterprise firewalls and proxies but agreed, support
> for all the HTTP verbs is sadly limited. That's exactly what the
> X-HTTP-Method-Override header was invented for.
>  
> 
>     Perhaps the compromise position is to work both ways:
> 
>     POST/GET/PUT/DELETE /<object>  accepts all 4 CRUD operations
>     POST /<object>/set             alternative form of 'U' (if cannot PUT)
>     POST /<object>/destroy         alternative form of 'D' (if cannot
>     DELETE)
>     POST /<object>/create          alternative form of 'C' (for symmetry)
>     GET /<object>/info             alternative form of 'R' (for symmetry)
> 
> 
> I'd be more inclined to go with one or the other, and in case it's not
> obvious yet I've got my sights set on the myriad Google GData clients
> <http://code.google.com/apis/gdata/clientlibs.html> (Java, .NET, PHP,
> Python, Objective-C and Javascript, all under Apache licensing), and of
> course the army of developers who are already familiar with their APIs.
> 
>     > Non-CRUD operations such as start, stop, restart, clone, snapshot,
>     etc.
>     > can be exposed by "actuator" URLs, which fits nicely with HATEOAS.
> 
>     The actuator URLs for these can then fit in alongside the alternative
>     actuator forms of the CRUD operations themselves.
> 
> 
> Right, the format for the URLs should be specified too, but the client
> can tell what methods to expose based on which are present (thus saving
> the user from pushing buttons that are guaranteed to result in errors,
> like "start"ing an abstract template or "stop"ping a stopped machine).
> 
> Sam
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg




More information about the occi-wg mailing list