Should we always validate resource id in url and body in HTTP PUT request?

Question

Suppose I am updating a employee record

url - /api/employees/10

body -

{ 
  id : 10,
  name : xyz
}

Should I validate for the employee id in url is same as in response? Because one employee can hit the url himself but update the data of another employee by sending another value in the PUT body.

Answer 1

If you have to validate, it's likely that you want to use POST. A POST is not idempotent and you are supposed to manage the change.

PUT is idempotent, and it just creates a resource. It implies that you don't actually care what id 10 is and whether it is a new id or an existing id. You just replace id 10 with the resource you supply. You only use PUT when you know what the uri should be.

Answer 2

Yes, if the representation of the object in the body contains its own key, you should validate that it matches the key from the URL. It's an error for the client to try to PUT an object at /api/employees/10 that isn't a valid value for employee #10's record, so you should check for that and report it as an error just as you would check that the object has correct syntax.

I believe that the best error code to return in this case is 422 Unprocessable Entity , but I might be wrong about that.

Another thing you can do instead is don't include the key at all in the body. However I find that keeping the key in makes sense for consistency with the way the same type of object is represented in other parts of the API (possibly embedded inside other objects). This is especially true when using XML (although it looks like you are using JSON here).