1

I'm creating an ASP.NET Web API application that will be accessed by mobile clients. I would like to use the client's User-Agent header to determine whether I should allow the client to connect to my server/API or to ask them to upgrade their client version.

To give a simple example, the client sends User-Agent: ClientV5 with every request. If the server considers ClientV5 to be out-of-date, wrong, etc., I'd like my server to reject the request and return a response along the lines of "Please upgrade your client to the latest version".

Is this a "misuse" of the User-Agent header, especially since this header will probably be set by the mobile web views on the various mobiles OSs?

Note that I do not want to keep older versions of my API available (/api/v1/..., /api/v2/..., etc.).

Josh Crozier
  • 233,099
  • 56
  • 391
  • 304
djikay
  • 10,450
  • 8
  • 41
  • 52

1 Answers1

1

Is this a "misuse" of the User-Agent header?

No, it's not. If you take the typical use case of a User-Agent as an example, browsers, they typically include the version number: Firefox/29.0

That being said, I would tend to encourage you to not use the User-Agent header for this purpose. If you ever decide to support different kinds of devices (example, a normal PC or mobile web browser) this will be an annoying issue to switch to something later.

Also, sometimes things bounce through proxies or anti-virus software which can make changes to several headers (Referrer, User-Agent, etc).

In general I think the accepted answer to this question, had it right:

For example, if API v3.0 is the latest API version, the following two
should be aliases (i.e. behave identically to all API requests):

http://shonzilla/api/customers/1234
http://shonzilla/api/v3.0/customers/1234
http://shonzilla/api/v3/customers/1234

The mobile application should attempt to go to the explicitly version-ed route on at least its initial request, if not all requests. And this will bounce them back if they are using an outdated version.

Additionally, this gives the flexibility of saying /customers/1234 is compatible for the last two versions, but /customers/add recently changed and would bounce back anything except the latest version. Is you ever desired that.

Good luck.

Community
  • 1
  • 1
arserbin3
  • 6,010
  • 8
  • 36
  • 52
  • I had a sneaky feeling using the `User-Agent` header may not have been a good idea and your response more-or-less confirmed it. I hadn't spotted the question you linked, thanks. – djikay May 21 '14 at 09:27
  • I suppose I could also add my own "custom" HTTP request header or I could even use the `Accept` header, both of which are presumably unlikely to be modified by proxies, anti-virus, etc. Would any of those be valid alternatives? – djikay May 21 '14 at 10:55
  • Yes, both of those are good alternatives. Depending on the possible future you see for that API, and whether it would ever involve browser access, then the URL could be the most future-safe. Its also just easier during development and testing. – arserbin3 May 21 '14 at 12:36
  • While it's hard to tell what the future holds, I'm pretty sure browser access is going to happen. I've read that changing the URI with v1, v2, etc. doesn't follow the REST principle, so I'm trying to be as "proper" as I can. – djikay May 21 '14 at 12:48
  • If you want to stay truly REST you could simply put the requirement on the client side, with a `http://example.com/api/version` request. The client can give up on a mismatch. If there's an initial authentication request, it can be returned there instead. – arserbin3 May 21 '14 at 17:04
  • Not sure about that, I'll have to think about it. Thanks. – djikay May 21 '14 at 18:00