[occi-wg] JSON Rendering proposal, rev 2

[alexander.papaspyrou at tu-dortmund.de]

Hi Ralf,

Excellent work you did. Like it I. Comments inline.

Am 27.02.2012 um 22:32 schrieb Ralf Nyren:

> I have tried to incorporate much of the feedback received so far. Short summary:
> - Use separate media-types for rendering the different payload contents. Inspired from Florians references to the CDMI spec.

I'm not sure whether I really like the different media types, and I think it could be done without. This would make the content type negotiation easier, if you consider clients that handle different renderings at the same time in conjunction with servers that deliver several different renderings.

If we go for HTTP-based usage of the JSON rendering, it should just be application/json.

This brings me to the second issue I have: I don't think that it is a good idea to mix JSON data rendering, and the introduction of a JSON-based protocol. I am perfectly fine with the former, but for the latter, we really have HTTP. This might require certain modifications to the HTTP core API (although I wouldn't bet for it without checking), but it would keep things nicely separate.

Remember that JSON really is a data format, not a protocol. I am perfectly fine with providing a JSON rendering *for the core model* in terms of data representation, but integrating the protocol would be a similar mistake as it has been done with WS-Agreement, where we are stuck today with WSRF. Besides that, there is no reason forcing to use JSON over HTTP, if they don't want to: replacing the "href" by an URI (and maybe renaming it to "location" would allow for broader use of the JSON data rendering; and everything else is pretty agnostic of HTTP and friends.

And btw.: HTTP gives us all we need to do the protocol part; the RESTfulness lies in there, anyway. Therefore, the interaction part should be described there, agnostic of the content-type (after all, that's what HTTP is about). That way, people could implement the HTTP protocol rendering once, and reuse it for several OCCI data renderings.

Let's not do the same mistake we did for the HTTP rendering yet again...

> - Try to make the single-instance format more lightweight and not duplicating any information available through the discovery interface. Thanks Jamie.

That actually I like very much. It might be nice to think about a shallow/deep rendering option on the protocol level, but that's just a thought.

> - Use the "marker" concept from OpenStack for pagination as suggested by Andy.

This is also something that should be taken care of in the protocol, rather than the data format. Why on earth would people want to see this if the protocol they use only delivers batches of things? And in fact, looking at the spec, it has been done on the HTTP level, anyway.

Frankly, this should be something to be added to the HTTP protocol rendering and made available to all data representations, rather than in a proprietary, JSON-specific way only.

> - "range" and "default" attribute properties as requested by Florian.

Great idea. We might want to consider pushing this upstream to core.

Ready to be clobbered by the mongol hordes…

-A.

-- 
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alexander Papaspyrou.vcf
Type: text/directory
Size: 498 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120229/01107fa4/attachment.bin>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4678 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120229/01107fa4/attachment-0001.bin>