What is the recommended way to handle the presence of read-only fields in the request body?
For example, a
user resource may have a permanently read-only attribute
username. If a PATCH request comes in with the
username specified, should the field be ignored (updating any other specified fields), or should the server return e.g. 400?
I’m currently returning an error response, because I like pushing clients to behave correctly instead of simply ignoring what may be bugs in the clients. (For this particular example, users may wonder why the username never seems to change correctly when submitting a form. Returning an error forces client devs to correctly implement the API specification, which of course states that
username is read-only.)