-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: V4.01_CS01
-
Fix Version/s: V4.01_CS02
-
Component/s: Protocol
-
Labels:
-
Proposal:
-
Resolution:
We recently updated section 11.4.3 “Update an Entity” and added: On success the service MUST respond with 204 No Content, or with 200 OK if the request included a return Prefer header with a value of return=representation.
Unfortunately that is not backwards-compatible with OData 4.0. Since the 4.0 spec says nothing at all about what the server will do when the client indicates no preference, a 4.0 server can be spec-compliant if it returns 200 with content (even without seeing a preference). The addition of that text will have the effect of retrospectively making some 4.0 services non-compliant. Also it sets a precedent that the server MUST respect preferences (at least return=representation for PATCH/PUT). Previously (AFAIK) servers could ignore preferences (although it could be argued that sections 11.4.2 and 11.4.7.1 already set such a precedent for POST responses).
Better would be if 4.01 required a 4.01 response to have status 200 (with content) for PATCH/PUT, unless the client specifies “Prefer: return=minimal” and the server chooses to respect the preference (and for 4.0 responses, no requirement one way or the other since that is the way the 4.0 spec has it). For consistency, sections sections 11.4.2 and 11.4.7.1 should be reworded so as not to force the respecting of preference return=minimal.
The requirement (by default) for content in a PATCH/PUT response is more important than it was for 4.0, since with “deep update” clients may need the ability to obtain keys. Not having any way for a client to be sure of getting 200 (with content) in a PATCH/PUT response is problematic (it was not that bad with 2.0 - 4.0, since an extra query could always be sent to get the latest state, and there were no "new keys" available).