It is given where where is an error to attempt to update a field in unexpected or conflicting values mentioned in the payload.
For example, I am trying to update a user for some value, I do a get on it modified few values and pass it as PUT payload. Now by mistake I mis types userid, username or email with some other fields, now server cannot accept payload since it finds inconsistency or conflicts between some readonly fields like email, userid etc. so it will send a 409 Conflict http code.
409 is also thrown in case of version conflict:
For example, you may get a 409 error if you try to upload a file to the Web server which is older than the one already there – resulting in a version control conflict.
the Robustness Principle states “Be conservative in what you do [send], be liberal in what you accept.” If you agree philosophically with this, then the solution is obvious: Ignore any invalid data in
PUT requests. That applies to both immutable data, as in your example, and actual nonsense, e.g. unknown fields.
Lets take an example, I have payload and there are few fields like id, username etc which are non writable. If someone sends them in PUT payload, I have 3 options,
- Do validation against read only or non writable fields (or any extra fields) and return 400 validation error. ( breaks backward incompatible )
- Follow robustness principle and all the payload with any fields including non writable fields, however if the value does not match ( the id or username in payload does not match with DB data / get on resource ) return HTTP 409 conflict.
- Silently ignore any other fields and its values and update only modifiable fields. ( supports any payload and makes it back ward compatible.
I really dislike the equality check with 409 because it invariably requires the client to do a
GET in order to retrieve the current data before being able to do a
PUT. That’s just not nice and is probably going to lead to poor performance, for somebody, somewhere. I also really don’t like 403 (Forbidden) for this as it implies that the entire resource is protected, not just a part of it. So my opinion is, if you absolutely must validate instead of following the robustness principle, validate all of your requests and return a 400 for any that have extra or non-writable fields.