Difference between revisions of "201801 Versioned API"
(Created page with "Jan 2018 Proposals __NOTOC__ =Track Name= Versioned API ==Submitting WG/Project/Implementer Group== FHIR-I + ITS ==...") |
|||
| Line 90: | Line 90: | ||
Notes: | Notes: | ||
| − | * this | + | * this scenario is the actual expectation for multi-versioned API: the URL identifies a single resource |
| − | + | * it's up to the server how it performs the conversion in the backgroudn | |
| − | |||
| − | |||
| − | |||
| − | + | ===Scenario #4: Implicit Version Conversion === | |
| + | ====Action==== | ||
| + | Client posts/puts Patient resource of one version to the server but claims it is another version. | ||
==== Criteria ==== | ==== Criteria ==== | ||
| − | + | * Success Criteria: Server reads what it can following version compatibility rules, or returns an error if the differences are not consistent with the versioning rules | |
| − | * Success Criteria: | + | |
| + | Notes: | ||
| + | * This stream needs to test more than just Patient - Patient doesn't have enough changes | ||
==TestScript(s)== | ==TestScript(s)== | ||
| − | + | no test script possible | |
==Security and Privacy Considerations== | ==Security and Privacy Considerations== | ||
| − | + | n/a | |
| − | |||
| − | |||
| − | |||
Revision as of 00:00, 23 October 2017
Track Name
Versioned API
Submitting WG/Project/Implementer Group
FHIR-I + ITS
Justification
Interest is growing in how to manage cross-version use of the FHIR API. This connectathon stream tests out 2 aspects of cross-version use of the FHIR API:
- a single end-point that supports more than one version (Scenarios #1 and #2)
- how to handle changes a resource between versions (Scenarios #3 and #4)
Proposed Track Lead
Grahame Grieve (Connectathon_Track_Lead_Responsibilities)
Expected participants
- Grahame Grieve (server + client)
- ?
Roles
Server: provides the FHIR API Client: use the FHIR API
Scenarios
The versioning track is divided into 4 scenarios. Scenarios 1 and 2 deal with API differences, and scenarios 3 and 4 deal with managing content differences between FHIR versions.
- Specifying the FHIR version using a content type parameter
- Asking the server which versions it supports
- Explicit Version conversion
- Implicit Version conversion
In theory, the techniques for this stream apply to all resources. However, for simplicity, the stream will focus on searching, reading and writing Patient resources. Servers that do not support read/write on patient resources may still participate.
Scenario #1: Specifying Server Version
Action
Client makes a request of the server for e.g. GET [base]/Patient/example, with the Accept: header containing a standard FHIR content type as negotiated with the server, but also containing the content type parameter
fhir-version: rX
where X is the formal release (2,3, or 4 for the current build at this time)
Criteria
Success Criteria: The server returns a patient resource for the nominated version of FHIR, or an error if it is not supported.
Notes:
- search is required to work correctly for the nominated version of FHIR, and that the careProvider search parameter was renamed. Note also the content of the Patient.contact.relationship code set changed
- for this scenario the server is not required to ensure that the R2/R3/R4 versions of the resource are synchronised (see scenario #3 below)
Scenario #2: Server Version discovery
Action
Client makes the request GET [base]/$versions
Server returns a parameters resource containing one or more version parameters, one for each version supported. The possible versions are (at this time: r2, r3, r4).
Criteria
- Success Criteria: server returns correct list
- Bonus: if the client request is plain json (not FHIR json) then the server returns a simple json containing a versions array
{
"versions": ["r2, r3"]
}
Scenario #3: Explicit Version Conversion
Action
Client posts/puts Patient resource to the server using one version, and [it or another client] reads it as another version. The semantics of the resource must be updated properly
This uses the server to do version conversion of a resource. Note that (for now?) this is 2 calls; we are not testing an inline version conversion operation
Criteria
- Precondition: server claims to support both versions
- Success Criteria: server can convert
Notes:
- this scenario is the actual expectation for multi-versioned API: the URL identifies a single resource
- it's up to the server how it performs the conversion in the backgroudn
Scenario #4: Implicit Version Conversion
Action
Client posts/puts Patient resource of one version to the server but claims it is another version.
Criteria
- Success Criteria: Server reads what it can following version compatibility rules, or returns an error if the differences are not consistent with the versioning rules
Notes:
- This stream needs to test more than just Patient - Patient doesn't have enough changes
TestScript(s)
no test script possible
Security and Privacy Considerations
n/a
