REST headers in FHIR

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

About David Hay
I'm an independent contractor working with a number of Organizations in the health IT space. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the FHIR standard. I'm the author of a FHIR training and design tool - clinFHIR - which is sponsored by InterSystems Ltd.

Leave a Reply

Discover more from Hay on FHIR

Subscribe now to keep reading and get access to the full archive.

Continue reading