[occi-wg] "Approachability" of API

Richard Davies richard.davies at elastichosts.com
Mon May 18 06:23:11 CDT 2009


Richard Davies wrote:
> My feeling is that a POJ/POX rendering is a smaller amount of JSON/XML
> [than AtomPub] with less wrapping around it

Sam Johnston wrote in a separate thread:
> IOW, your average [AtomPub] request to ElasticHosts is going to be
> skeletal while your average request to VMware (if they ever implement it)
> will be relatively fat. Who cares?


This is something which I love to understand better - how skeletal the
minimum AtomPub request can be. This would help me to understand how much
"weight" which we are taking on comparing AtomPub vs. POX/POJ.

Sam - can you help me work this out - I've started below...



As a thought experiment, consider starting from a POX rendering of
the nouns, verbs and attributes in the style of my second example at:
http://www.ogf.org/pipermail/occi-wg/2009-May/000526.html
with the same URLs and verb behaviours as I'd proposed at:
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/SimpleJSONRendering

This is already (and deliberately) somewhat in the style of AtomPub. For
example, the noun endpoints are similar and my <object> tags contain roughly
the same as the AtomPub <entry> tags would.

Now compare this with a minimal AtomPub such as: http://occitest.appspot.com/

What is the set of changes I need to make to get from this POX to the
minimum AtomPub? Assume for this thought experiment that I don't want to
benefit from any additional services which AtomPub provides, but just want
the same experience as with the POX rendering.


I can name a few:

- There's a <feed> tag which wraps all of the entries/objects. It has
  various other subtags of its own (e.g. title, subtitle, author). Am I
  right that all of these are static and could be bolted on by a server or
  ignored by a client which skips straight to the entries?

- Am I right that this <feed> tag is only relevant when getting the entire
  overall feed? When inserting or updating individual entries we still send
  the entry alone.

- There are 'updated' tags on every entry. Can these be ignored by clients
  and set to the current time by servers?

- All UUIDs are prefixed by urn:uuid:

- Each entry has a link confirming its own end point (versus the POX
  rendering just defines fixed end points for objects).

- Each entry will have links confirming all of its actuators (versus the POX
  rendering just defines a fixed URL scheme for the actuators).

- The syntax for linking one noun to another is different, and additionally
  specifies a schema for the link (defined as fixed in the direct rendering).

- I believe that the nouns' attributes will end up inside a <content> tag
  inside the entry, rather than being at the top level.

- A HTTP DELETE call has to specify an ETag version as part of a delete call

Is that list correct? What else is there?



More information about the occi-wg mailing list