CODEWITHSUNDEEP
httprest
svckr
svckr

Reputation: 839

Should I use the Content-Location header this way?

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...

Upvotes: 5

Views: 1895

Answers (2)

Julian Reschke
Julian Reschke

Reputation: 42045

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

Upvotes: 1

Filip
Filip

Reputation: 3094

According to RFC 2616:

The Content-Location entity-header field MAY be used to supply 
the resource location for the entity enclosed in the message 
when that entity is accessible from a location separate from 
the requested resource's URI.

and 

The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource 
corresponding to this particular entity at the time of the request.

so generally, yes, you can use Content-Location header to identify origin resource. Main disadvantage of using of extension suffix is that you are making another URLs, e.g. /users/bob, /users/bob.vfc, /users/bob.html are three different resources.

Upvotes: 0

Related Questions