Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-680

Clarify use of if-match with actions

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: V4.0_OS
    • Fix Version/s: V4.0_ERRATA01
    • Component/s: Protocol
    • Labels:
      None
    • Environment:

      [Applied]

    • Proposal:
      Hide

      Clarify that, when invoking data modification request or an action advertised on an entity that has an associated etag, the etag should be specified in an if-match header when invoking the action.

      Show
      Clarify that, when invoking data modification request or an action advertised on an entity that has an associated etag, the etag should be specified in an if-match header when invoking the action.

      Description

      Section 8.2.4, Header If-Match, states the following:

      "If an entity set is annotated with the term Core.OptimisticConcurrency (see [OData-VocCore]) and the client does not specify an If-Match request header in a Data Modification Request or Action Request, the service MUST respond with a 428 Precondition Required and MUST ensure that no observable change occurs as a result of the request."

      This is true for data modification requests, but not generally true for action requests; an action request may operate on a single entity, a set of entities, or data unrelated to any entities. And, action requests may be invoked without having previously retrieved an entity from which to obtain an etag.

      The most we can say is that an etag should be specified when invoking an action bound to a single entity for which an etag has been retrieved (i.e., an "advertised" action).

      Also, it's always bugged me that we tie this to the OptimisticConcurrency annotation, as opposed to the presence of an etag in the response. The general rule should be: if you get an etag, provide it in an if-match header of any update/action on that entity.

        Attachments

          Activity

            People

            • Assignee:
              mikep Michael Pizzo (Inactive)
              Reporter:
              mikep Michael Pizzo (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: