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

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

#3

I don’t think, that returns error, on try to write read-only attributes are right. Cause client never know which of attributes are read-only. So IMHO server should just ignore read-only fields. Like imagine that client at first have to identify attributes which are read-only and after that can send valid request, it’s ridiculous.

#4

Cause client never know which of attributes are read-only.

They’d certainly know which field was read-only; permanently read-only fields would be documented, and the returned error object would also contain the prohibited field in pointer.