>> >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 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:22:29 GMT