Why does collection+json use anonymous objects instead of key value pairs

Question

I'm trying to find a data schema which can be used for different scenaries and a promissing format I found so far is the collection+json format (http://amundsen.com/media-types/collection/ ).

So far it has a lot of the functionallity I need and is very flexible, however I don't get why it uses anonymous objects ( example: {"name" : "full-name", "value" : "J. Doe", "prompt" : "Full Name"}, ) instead of simple key value pairs. (example: "full-name": "J. Doe", ).

I see how you can transfer more information like the prompt, etc. but the parsing is much slower and it is harder to create a client for it since he has to access the fields by searching in an array. When binding the data to a spezific view, it has to be know which fields exists, so the anonymous objects have to be converted into a key value map again.

So is there a real advante using this anonymous objects instead of a key value map?

Answer 1

I wrote this question and then forgott about it, but found the answer I looked for here:

https://groups.google.com/forum/#!searchin/collectionjson/key/collectionjson/_xaXs2Q7N_0/GQkg2mvPjqMJ

From Mike Amundsen the creator of collection+JSON

I understand your desire to add object serialization patterns to CJ. However, one of the primary goals of my CJ design is to not support object serialization. I know that serialization is an often-requested feature for Web messages. It's a great way to optimize both the code and the programmer experience. But it's just not what I am aiming for in this particular design.

I think the extension Kevin ref'd is a good option. Not sure if anyone is really using it, tho. If you'd like to design one (based on your "body" idea), that's cool. If you'd like to start w/ a gist instead of doing the whole "pull" thing, that's cool. Post it and let's talk about it.

On another note, I've written a very basic client-side parser for CJ (it's in the basic folder of the repo) to show how to hide the "costly" parts of navigating CJ's state model cleanly. I actually have a work item to create a client-side lib that can convert the state representation into an arbitrary local object model, but haven't had time to do the work yet. Maybe this is something you'd like help me with?

At a deeper (and possibly more boring) level, this state-model approach is part of a bigger pattern I have in mind to treat messages as "type-less" containers and to allow clients and servers to utilize whatever local object models they prefer - without the need for cross-web agreement on that object model. This is an "opinionated design model" that I am working toward.

Finally, as you rightly point out at the top of the thread, HAL and Siren are much better able to support object serialization style messages. I think that's very cool and I encourage folks (including my clients) to use these other formats when object serialization is the preferred pattern and to use CJ when state transfer is the preferred pattern.

Answer 2

I think that the main reason is because a consumer client does not need to know in advance the format of the data.

As it is proposed now in collection+json, you know that in the data object you will find stuff about data simply by parsing through it, 'name' is always the identifying name for the field, 'value' is the value and so on, your client can be agnostic about how many fields or their names:

{
 "name" : "full-name", 
 "value" : "J. Doe", 
 "prompt" : "Full Name"
},
{
 "name" : "age", 
 "value" : "42", 
 "prompt" : "Age"
}

if you had instead

{
 "full-name" : "J. Doe", 
 "age" : "42"
}

the client needs to have previous knowledge about your representation, so it should expect and understand 'full-name', 'age, and all the application specific fields.