I much prefer the JSON-API approach by Yehuda Katz, et al.[1] https://gist.github.com/21echoes/a1ca3e4376262da32297 https://gist.github.com/21echoes/a1ca3e4376

I much prefer the JSON-API approach by Yehuda Katz, et al.[1] https://gist.github.com/21echoes/a1ca3e4376262da32297 https://gist.github.com/21echoes/a1ca3e4376262da32297 It's definitely designed to be used in a RESTful-esque situation (the reference keys are a type/id tuples), but that's the dominant JSON use case anyway. For an example of why you'd want type/id tuples over JSOG's plain string @id -- while in the given JSOG example, all items are People, referencing an Address object from Sally (so that Bob can deliver her gift) introduces a potential conflict between Address @id: 1 and Person @id: 1. To disambiguate, you could of course prefix all "@id" value strings with e.g. "address-" or "person-", but then you've just re-invented JSON-API's solution, while making your @id not a real id (not usable in cases like e.g. `api.example.com/resource/<id>`, etc.). The other solution is to say that JSOG @id's are only for use in one response parsing situation, and could be discarded afterwards. But that seems like quite a waste -- what if e.g. your API wanted to be able to send @id references over the wire without the overhead of sending the whole referenced object? [1]http://jsonapi.org/ http://jsonapi.org/