Http status code for PUT when path parameter ID is different than request body ID - put

Question

I am using put to modify a resource. I was wondering what is the appropriate status code to return when the id given in the path is different from the id given to the body of the resource.
e.g.
REST api action method is: /resources/{id}
Body:
{
"id": "test",
"name": "my_resource"
}
What HTTP Status Code should be returned to the following curl request?
curl -X PUT 'localhost:8080/resources/test2' \
--header 'Content-Type: application/json' \
--data-raw '{
"id": "test",
"name": "my_resource"
}'

Answer 1

You can probably make an argument for any of
403 Forbidden (I understand your request, and I decline to fulfill it - see response body for details)
409 Conflict (Your proposed change conflicts with the current state of the resource - see response body for details)
422 Unprocessable Content (The body of your request is internally consistent, but doesn't make sense here - see response body for details).
For the general purpose elements of the HTTP application itself, it doesn't very much matter which of these you choose - they are all non-cacheable errors, the component isn't going to have any sort of automatic recovery, etc.
One tie breaker you might consider is how these entries are going to appear in your access logs / how your automated monitoring is going to handle them: if you want these messages to stand out in your logs, then you'll want to choose status code that's not overloaded with other meanings.
For more details, see section 15.5 of HTTP Semantics
Do you think that a 500 Internal Server Error with a proper explanation would be fine as well or is it confusing?
5xx Server Error is inappropriate when the information in the request is the source of the problem, because the form of the request is the client's responsibility, not the server's.
Loosely: 4xx covers all of the cases where the server is announcing "you should not have asked for that". 5xx is for variations of "what you asked for is fine, but I couldn't do it."
See the HTTP Semantics spec, in particular sections 15.5 and 15.6 (or, if you prefer the earlier reference, RFC 7231 6.5 and 6.6)