[OASIS Issue Tracker] (ODATA-1263) Requirement for 204 (No Content) with 11.4.3 "Update an Entity" is not backwards compatible

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Evan Ireland created ODATA-1263:
-----------------------------------

             Summary: Requirement for 204 (No Content) with 11.4.3 "Update an Entity" is not backwards compatible
                 Key: ODATA-1263
                 URL: https://issues.oasis-open.org/browse/ODATA-1263
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: Bug
          Components: Protocol
    Affects Versions: V4.01_CS01
         Environment: 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).

Â
            Reporter: Evan Ireland






--
This message was sent by Atlassian JIRA
(v7.7.2#77003)