[OASIS Issue Tracker] (ODATA-1616) Clarify rules around results returned from Create/Update

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

Michael Pizzo created ODATA-1616:
------------------------------------

             Summary: Clarify rules around results returned from Create/Update
                 Key: ODATA-1616
                 URL: https://issues.oasis-open.org/browse/ODATA-1616
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: New Feature
          Components: Protocol
    Affects Versions: V4.01_OS
         Environment: Proposed
            Reporter: Michael Pizzo
             Fix For: V4.02


In ODATA-1609 we defined that a create or update request with query parameters would return success if the resource was created or updated, even if a response could not be generated.

Clients can specify that they desire a response through a Prefer header (return=representation).

In 4.01 we added the ability for the client to specify select and expand query options for a create/update request, and suggested that presence of the select or expand would imply the user's intent to return results. However, with OData-1609 we are left with a situation in which the select and expand is ignored and yet we return a success code, meaning that adding select and expand indicates, at most, a preference, rather than a requirement to return results.

In 4.02 we should clarify that clients should couple the addition of a $select/$expand to a create/update statement with a return=representation preference if they want a result returned. Services then return a preference-applied header specifying return=representation if a response can be returned, or return=minimal if no response is returned. Note that it is always valid for the service to return a result even if the create/update is not specified, so any services that return results without the presence of a return=representation are not out of compliance, but clients should specify the preference as well as any select or expand in order to get results.

Alternatively, we could say that the presence of a $select/$expand implicitly sets the preference for return=representation, and the service shouldÂbehave as if a return=representation preference had been explicitly specified, including returning a preference-applied (unless a return preference had been explicitly specified, in which case it should take precedence â i.e., if the client specifies $select/$expand and return=minimal, then service should omit a response body).



--
This message was sent by Atlassian Jira
(v8.3.3#803004)