Andy McKay

May 24, 2015

Accept Header


Recently I used an endpoint that had the following HTTP Accept Header:

*/*; q=0.5, application/xml

This server is saying it will accept “application/xml”, but if that’s not available, then it will accept anything. The “q” indicates that “application/xml” is preferred.

The assumption is that if you send a piece of content, you will send an appropriate HTTP Content-Type Header. Then the server will know how to parse it.

This server wanted a token, just some string, echoed back to it. Given the HTTP headers, it seemed perfectly for me to send:

Content-Type: application/json
"some token"

Or even [1]:

Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?><token>some token</token>

As it turned out, it only accepted one thing and thats “test/plain” so something like:

Content-Type: text/plain
some token

This endpoint was hit using web interface, which was hitting a remote server, so took a little time to debug. But here’s the thing, I think accepting */* is a little unusual, unless you are you really going to accept anything, really anything? Will you accept text/csv, how about audio/ogg or video/ogg? Here’s one list of types [2].

The advantage of using a limited Accept header is that the server and client in question can figure things out without you having to do extra code. If the server explicitly declares what kinds of responses it can accept, then the client can check it can actually return the data encoded in that manner.

If your endpoint sends a */* Accept header and someone sends you something you don’t know how to parse, hopefully you’ll send them back a 406 response back. To tell the caller that you don’t Accept that kind of response.

In this example, I’ve been talking about a server API. But of course this is for anything in the HTTP world, for example my browser sends the following: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. It would much rather rather have HTML or XHTML, but will Accept anything and then do its best to render it. That seems reasonable for a browser.

But for an API that only accepts JSON or XML? Maybe we should make an effort to tighten up our Accept values on our APIs [3].

Footnotes

  1. Although it was never stated what the syntax for the XML was, so who knows.
  2. There isn't really a definitive list.
  3. Yes, that includes some APIs I've written.