One thing that came up today during some development that we are doing here concerns the use of HTTP headers when a client is making REST calls on a FHIR server. They are all clearly documented in the spec, – and there’s also a nice summary, but I’m just pulling them out here so I don’t waste so much time the next time I forget them (and Richard – who is developing the FHIR server – said I should – kind of like writing lines on the blackboard I suspect – “I will not forget to set the correct headers” repeated 20 times)…
- When making a query, to specify what format you want the server to return data in, use the Accept header. The value should either be application/json+fhir or application/xml+fhir (Though a bundle is slightly different with application/atom+xml for xml). The Server will set a Content-Type header to tell the client the format of the response (It doesn’t have to honour the Accept)
- When sending data to a server, use the Content-Type header to indicate the format. Same mime-type options as above.
- If updating a resource, it’s a good idea to put the current version-specific id in the Content-Location header. If the server is enforcing optimistic locking then it will need it – otherwise they will be ignored.
(you can also put the mime-type in an _format parameter if you can’t get at the headers).
So. There it is. Now…
I will not forget to set the correct headers again
I will not forget to set the correct headers again
I will not forget to set the correct headers again
…