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 organizations like Lyniate, CSIRO in Australia and the New Zealand Ministry Of Health. 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 new FHIR standard.

Leave a Reply

%d bloggers like this: