Read-only fields in request body - ignore vs. 400

#1

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.)

0 Likes

#2

FWIW, I’m working on an implementation and plan to error on read-only fields. But I’ll continue with the update to gather any other possible errors before returning the error objects (in case there are multiple problems with the update request).

0 Likes