Should I use the Content-Location header this way?

Question

Preface:

After reading a lot about HTTP and REST, you have spent a few hours devising a cunning content-negotiation scheme. So that your web API can serve XML, JSON and HTML from a single URL. Because, you know, a resource should only have one URL and different representations should be requested using Accept headers. You start to wonder why it took the web 20 years for that realization.

And that is when reality slaps you in the face.

So to help browsers (and yourself trying to debug) with coercing your service to serve the desired content type you do what every self-respecting REST evangelist would despise you for: Filename extensions.

Eternal torment in hell notwithstanding, is the following use of Content-Location + .ext acceptable?

Say we have users at /users/:loginname for example /users/bob. This would be the API endpoint for anything that is capable of setting a proper Accept header. But for any possible Content-Type (or at least some), we allow an alternate method of access and that is a URL with a filetype suffix. For example /users/bob.html for an HTML representation. Let's assume (and that is a big assumption to make) login names will never contain a period/dot.

Request:

GET /users/bob.json HTTP/1.1  
Host: example.com

Response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 14
Content-Location: /users/bob

{"foo": "bar"}

This would allow me to encode alternative ways to access (in this case) the user information. For example a link to a user page could be <a href="/users/bob.html">Bob</a>. A link to a vCard (to add the user to the Address-Book/Outlook/anything) would be <a href="/users/bob.vcf">Bob</a>.

Are there any pitfalls I have missed? What would be pros/cons of this?

Edit: This popped up a bit late for me to notice. And even though it touches the subject and is really helpful, I think it's not exactly what I'm looking for...

Answer 1

As far as I can tell, you use Content-Location exactly the wrong way; it should point to the more specific URI.