Why are 'type' and 'id' attributes required in an update request?


#1

I am implementing a new API and follow the json api spec. (partial) updates are done using the PATCH request (on single resources). This means the request is always send to: /resource/{id}/

What I don’t understand is the requirement to add the ‘type’ and ‘id’ attributes in the request as described here: http://jsonapi.org/format/#crud-updating

Both of them are known because of the endpoint URL. E.G. an update to an article with id 5 is always done on ‘/articles/5’ but still its required by the spec to add both the id and type attributes.

Why is this?


#2

Basically, it’s for consistency, because the type and id can’t be inferred in all cases, and we don’t want clients have to know/think about when it’s needed and when it isn’t. Here’s a relevant passage from the spec about type:

Note: The type member is required in every resource object throughout requests and responses in JSON API. There are some cases, such as when POSTing to an endpoint representing heterogenous data, when the type could not be inferred from the endpoint. However, picking and choosing when it is required would be confusing; it would be hard to remember when it was required and when it was not. Therefore, to improve consistency and minimize confusion, type is always required.

And, as we expand the spec in new directions (e.g. #795-style operations), there’ll likely only be more cases where the ability to infer type/id breaks down.


#3

In REST (and HTTP), URLs are supposed to be opaque. JSON API doesn’t place any particular restriction on what your URLs look like, so we cannot guarantee that you could do any kind of inference from the URL.