2015May core #469 - How is resource contention handled on delete?

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU1 [deprecated]
    • FHIR Infrastructure
    • REST (http)
    • 2.1.0.12
    • Hide

      Add a note to read/delete operation s about returning an ETag for a deleted resource

      Show
      Add a note to read/delete operation s about returning an ETag for a deleted resource
    • Grahame Grieve / Andy Stechishin: 3-0-0
    • Clarification
    • Non-substantive
    • DSTU1 [deprecated]

      Existing Wording: Resources that have been deleted may be "brought back to life" by a subsequent update interaction using an HTTP PUT.

      Comment:

      It is not clear how resource contention is to be handled whena delete action is performed. This should be thoroughly explained. For example, what is system A and System B both retrieve the latest version of a resource. System A, using the existing Etag, deletes the resource, and subsequently System B, using the same ETag updates the resource. Will the resource be "brought back to life", or does the delete operation somehow update the ETag and thus the server returns a 412. If the later is the case, how does a system "get the new ETag to bring a resource "back to life"

            Assignee:
            Unassigned
            Reporter:
            corey_spears#1
            corey_spears#1
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: