Type name (as endpoint) for fetching related from links

1

Hi,

I’ve a question about whether I understand type names correctly. Let’s assume the following request:

Request: http://example.com/articles/1/relationships/author
Response:

{
  "links": {
    "self": "http://example.com/articles/1/relationships/author"
  },
  "data": {
    "type": "people",
    "id": "12"
  }
}

Am I right, that a client may be correctly assuming, that the author can be fetched from http://example.com/people/12? If that is not the correct request and the related property is missing from the links section, in which way is it recommended to define where to find the author/people?

Thanks
gossi

2

Correct me if I’m wrong, but this is likely implementation defined. In our case, our framework provides a hierarchical security model which exposes only select types from the root level (everything else must be accessed by drilling into that object’s path). That is, this assumption may or may not be true in our framework depending on whether or not you exposed this entity at the root level.

Generally speaking, if something is at the root level, I do believe the URI is of the form:
/<type>/<id>

though I cannot find anywhere in the spec where this is actually explicitly articulated. Overall, perhaps a more reliable construct to use for finding related objects is, instead, a links object.

3

That’s the question, I’d hope to find an answer here. Well, not specifically, if the spec is explicitely mentioning something but what was the intention in mind, when writing the spec with type names.

4

From the FAQ:

JSON API has no requirements about URI structure, implementations are free to use whatever form they wish.

This seems to me a critical feature of JSON API because it decouples the server from the client. The client has to rely on explicit related links given by the server (which can change at any time), not on stitching the URLs together according to some predefined templates. If the server provides no related links, this means that the server doesn’t support browsing that relationship.

2 Likes
5

Thank you, that helped. Especiall this one…

… should make it’s way into the spec (and if it’s in there, I missed it :disappointed_relieved:)

6

To be clear, that part was just my interpretation. It’s also easy to imagine a sloppy server that neglects to send explicit links, but still works OK with clients that hardcode URL templates—you might have to work around that.