It was certainly not my intention to deprecate the GET parameter and make it harder for people who already use the API.
Authorization header is probably not a good idea. This header is mostly used by the web server and not the application on top. AFAIK, there’s no
Authorization: Token xxxxxx format either and I have never seen a token used in that way (except OAUTH which is a different story).
We could write an RFC and submit it, even though I doubt it makes much sense, because most people would rather manage the tokens in the application layer than the web server.
In the APIs I wrote, I used the header
TOKEN: token-here, but I’ve seen different names like
This topic is rather complex, because tokens are not supposed to be used as a security measure alone, but used in combination with an authorization scheme. Some even use a token instead of the password for basic authentication. But I think we can forego an endless discussion about the principles of token utilization. (It does not apply to us anyway.)
We don’t use authorization at all, so we only have to decide on a HEADER name.
The reason why I use
TOKEN is the following: it is succinct and self explanatory. e.g. what else would be the header TOKEN for when you connect to an URL
https://example.com/api/v1/endpoint? Developers who use an API know that they need a token, so there’s no reason to use an API prefix for TOKEN. However, I’ve heard the argument that there could be more than just one token, in which case the prefix were to help with distinguishing them. Valid point, but we don’t, thus no need.