PATCH expects id redundantly in URL and as a parameter

1

I try to implement a REST API following the json:api spec, but I am a bit confused.

In the “Updating Resources” section, the spec (v1.0) states that the …

resource can be updated by sending a PATCH request to the URL that represents the resource.

and

The PATCH request MUST include a single resource object as primary data. The resource object MUST contain type and id members.

A REST API would define PATCH /{resource}/{id}, just like it was done in the example in that section.

That begs the question why the id has to be provided as a parameter, when it is already available per URL. What if the IDs in the URL and in the parameter differ? Surely they must (as in MUST) always be equal?

I suppose non-REST APIs shall be possible, to, but as far as I can see, I would much prefer if ID could be optional.

Many thanks for the feedback!

Update: The DELETE call, on the other hand, seems to be fine without any further parameters, just DELETE /{resource}/{id}

2

Why?
I can’t see a good reason for making them different if they could be the same (indeed JSON API recommends this), but there’s no reason why a JSON API has to use this URL format, or even has to have only a single URL that refers to a resource.

Consider the example on the website:
http://example.com/articles/1/author and http://example.com/people/9 both refer to the same resource (at least at one particular time), and a client could issue a PATCH request to either URL to modify the author resource.

3

Indeed, thank you! I suspected I must have missed something obvious, and the example you gave clarifies it.