Issue 17376: Enable the use of version-aware resource URLs (hdata-ftf) Source: HL7 (Mr. Grahame Grieve, grahame(at)healthintersections.com.au) Nature: Uncategorized Issue Severity: Summary: Most of the changes requested in this section apply to 6.5 of the hData specification. FHIR will need to be able to access different versions of a resource. To enable this most effectively, the spec should support the following URL extensions on SectionDocuments for GET, PUT, and POST operations: (resourceURL) = (baseURL)/(sectionPath)/(sectionDocument) (versionAwareResourceURL) = (resource)/history/(version-id) where (version-id) is any unique string. Also, a GET on the (resourceURL) should return the representation of the resource in the HTTP body, a status code of 200, and a Content-Location header containing the (versionAwareResourceURL) of the current version of that resource. If the resource was deleted with a DELETE, the service SHOULD return a HTTP status code 410, with no body. However it MAY return a 404 as alternative. To enable safe updates, the following process MUST be used: • The client reads obtains the representation of the current version by performing a GET on the (resourceURL). This contains the reference to (versionAwareResourceURL). • The client makes the necessary changes to the state. • The client MUST then PUT the updates representation to the (resourceURL) and quote the versionAwareResourceURL in the Content-Location header of the PUT operation. • If the (versionAwareResourceURL) provided by the client is the current version, the server accepts the representation and persists the change, and returns a HTTP response with • a status code of 202 ok, • a Content-Location header with the (versionAwareResourceURL) of the new version, and • the representation of the new version of the resource in the • If the (versionAwareResourceURL) represents no longer the current version, the server MUST return a HTTP response with status code 412, a Content-Location header with the new (versionAwareResourceURL), and a representation of the latest version of the resource. Resolution: Revised Text: Actions taken: May 20, 2012: received issue Discussion: End of Annotations:===== M-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RUsFF05TKHRKKFjWfzyZybpEznS7nFClSG3Hj2ARqSY=; b=VSZMiqwFDIg9E1/XNeXowoslxp6QCUYuISJRXQdhPmk9QsWftsms+mIivRQStxZCof ZtTkfaIJo3TUTBOqreWHFEK1UMRiFmDzirFqQkahs4Ct3q4V++mgDWEvhvUxzOO3SIqq O+N7Z7biorZG0e+CW7HrDeHuMDH7AmhddX/E8lJFyTsaAWRSgDzkOXvGDLOfqTH1bQQ8 tm8jNlLUStjCUEE3yf6cNKDAwIiu3Yi645dGbijDIEA6spLqIV8tyy4sb7CKI18vw/s1 CGEEDNwbNc4MMVIS7BCQoKD+tvEQT8RwtW6nEtEbMEaorL24PJibwaNpx5LUkA1xIE03 2K0w== Sender: grahameg@gmail.com Date: Mon, 21 May 2012 13:35:04 +1000 X-Google-Sender-Auth: kclp1kfOO2QcAkq_OHdlQZr-CGA Subject: FHIR: Several Issues with OMG hData RESTful Transport to support an alternative realization of the RLUS PIM From: Grahame Grieve To: issues@omg.org Cc: Ewout Kramer , "Beuchelt, Gerald" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q4L3ZD9R024175 Dear OMG We (Ewout Kramer and myself) are technical leads on the HL7 FHIR project (http://www.hl7.org/fhir), which is a very practically orientated specification that has a RESTful component that overlaps somewhat with hData. The overlap occurs in two different ways: * FHIR uses a RESTful paradigm, and defines patterns of logical use of HTTP * FHIR defines resource content that would be useful to use in hData - and hData is a useful way to use them With regard to the first point, we believe that it would be useful for the hData protocol and FHIR to use the same patterns of usage for HTTP. this email identifies several issues where we believe that the hData restful transport specification could be improved, that would mean that we could act in harmony and refer to the OMG specification directly. With regard to the second, we will continue to work with the authors of hdata on that point. Both hData and FHIR are realizing a RESTful resource-centric architecture that implements the RLUS service functional model and the OMG PIM. In order to ensure a single implementation strategy and strengthen the overall technical quality of the specification, we request to consider the following changes to the OMH hData specification: 2. Enable the use of version-aware resource URLs Most of the changes requested in this section apply to 6.5 of the hData specification. FHIR will need to be able to access different versions of a resource. To enable this most effectively, the spec should support the following URL extensions on SectionDocuments for GET, PUT, and POST operations: (resourceURL) = (baseURL)/(sectionPath)/(sectionDocument) (versionAwareResourceURL) = (resource)/history/(version-id) where (version-id) is any unique string. Also, a GET on the (resourceURL) should return the representation of the resource in the HTTP body, a status code of 200, and a Content-Location header containing the (versionAwareResourceURL) of the current version of that resource. If the resource was deleted with a DELETE, the service SHOULD return a HTTP status code 410, with no body. However it MAY return a 404 as alternative. To enable safe updates, the following process MUST be used: . The client reads obtains the representation of the current version by performing a GET on the (resourceURL). This contains the reference to (versionAwareResourceURL). . The client makes the necessary changes to the state. . The client MUST then PUT the updates representation to the (resourceURL) and quote the versionAwareResourceURL in the Content-Location header of the PUT operation. . If the (versionAwareResourceURL) provided by the client is the current version, the server accepts the representation and persists the change, and returns a HTTP response with . a status code of 202 ok, . a Content-Location header with the (versionAwareResourceURL) of the new version, and . the representation of the new version of the resource in the . If the (versionAwareResourceURL) represents no longer the current version, the server MUST return a HTTP response with status code 412, a Content-Location header with the new (versionAwareResourceURL), and a representation of the latest version of the resource