- From: Kris Zyp <kris@sitepen.com>
- Date: Tue, 2 Sep 2008 17:55:43 -0600
- To: "Jamie Lokier" <jamie@shareable.org>
- Cc: "Robert Brewer" <fumanchu@aminus.org>, "Yves Lafon" <ylafon@w3.org>, "Julian Reschke" <julian.reschke@gmx.de>, <ietf-http-wg@w3.org>
>> >I'm a bit surprised that the top-level object in a JSON request would >> >be an array, though. For round-trip minimisation in AJAX applications >> >isn't it usual to send a bit of auxiliary metadata, or a few objects >> >together, and therefore the top-level JSON object tends to be an >> >object (i.e. several named data items) with one of its members being >> >an array, rather than the top-level object being an array itself? >> >> I am trying to move away from that approach, moving metadata to headers >> (ironically the offset and total count are the most common metadata >> items, >> and these are handled by the Content-Range header), allowing the actual >> content to be a "pure" representation of the resource, and therefore an >> array is the most natural top-level construct when requesting a >> collection >> of objects. > > Unfortunately, putting metadata into headers isn't a very tidy way of > representing metadata which has structure itself, which is not > uncommon with JSON. Not wishing to infer assent, but could we presume that if an alternate JSON structure was defined that had a top level object with prescribed property containing the array/items, that it could have application content type which provided the definition of how it should be segmented in response to an Range: items request? I think it is assumed that creating subset representations via a items range is content type specific (it would certainly be different for XML, for example), so it seems reasonable that application sub-types could also provide a definition of item range unit handling. (Concatenation can still remain content-type agnostic) Kris > > -- Jamie > >
Received on Tuesday, 2 September 2008 23:57:48 UTC