should it be possible to infer the endpoint from the type?
eg. /article for { “type” : “article” }, or can i use /articles for { “type” : “article” }
There’s this line in the spec:
“A server MUST return 409 Conflict when processing a POST request in which the resource object’s type is not among the type(s) that constitute the collection represented by the endpoint.”
Which seems to me a single endpoint may even support multiple types ?
To your first question, no. Self link and self link only is used for this. Platform conventions like Ember.js may exist which will allow this kind of inference, but it is not from a {json:api} perspective.
Polymorphism is supported in the spec, and even unrelated json:api types can be in the same collections. This is why it’s important you don’t try to infer any information from coincidental likeness in deployment and documents.
Thanks a lot.
Can you reference where exactly this is specified in the spec please?
It’s an area where the spec can be improved. The best is essentially proof by counter example. In the member names section the part “To enable an easy mapping” introduces the casual relationship between type and URL, and requires an understanding of the context - this is an ember convention - included by one of the {json:api} authors (Yehuda) who happens to be the author of ember as well. Sadly, this and a few other conventions portrayed as requirements cause a bunch of problems for people learning the spec who don’t use ember.
The rest of the conclusion stems from the opacity requirements of URLs in HTTP, and the polymorphic support you have already linked.
If your server implementation can’t support obfuscating resource collection root URLs, I would strongly argue the implementation is not fully compliant, and is likely making other assumptions which will break fully compliant libraries.