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?
I agree that the type/id pair is quite helpful when reading the graph! Interestingly, this does have the effect of limiting you to N top-level types, but I don't actually think that's a big deal. Most applications, if you break them down, only have like 3 real types (one of which is always "user").
JSOG solves one particular, widespread problem - reconstituting an object graph on the other side of a wire. As you said, the information is only meaningful during the exchange. JSOG isn't trying to solve some greater notion of object identity; that's your application's business.
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/