我应该这样使用Content-Location标头吗？

Question

前言:

在阅读了很多关于HTTP和REST的内容之后,您花了几个小时来设计一个狡猾的内容协商方案.这样您的Web API就可以从单个URL提供XML,JSON和HTML.因为,您知道,资源应该只有一个URL,并且应该使用Accept标头请求不同的表示.你开始想知道为什么它花了20年的时间来实现这个目标.

那就是现实让你黯然失色.

因此,为了帮助浏览器(以及您自己尝试调试)强制您的服务来提供所需的内容类型,您可以做每个自尊的REST传播者会鄙视您的内容:文件扩展名.

在地狱中永恒的折磨,是以下使用Content-Location+ .ext接受？

假设我们有用户在/users/:loginname例如/users/bob.这将是任何能够设置正确Accept标头的API端点.但对于任何可能的Content-Type(或至少一些),我们允许另一种访问方法,即具有文件类型后缀的URL.例如/users/bob.html,对于HTML表示.让我们假设(这是一个很大的假设)登录名永远不会包含句点/点.

请求:

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

响应:

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

{"foo": "bar"}

这将允许我编码访问(在这种情况下)用户信息的替代方法.例如,可以是指向用户页面的链接<a href="/users/bob.html">Bob</a>.指向vCard的链接(将用户添加到地址簿/ Outlook /任何内容)将是<a href="/users/bob.vcf">Bob</a>.

我错过了任何陷阱吗？这有什么优点/缺点？

编辑:这有点迟了让我注意到.即使它涉及到主题并且真的很有帮助,我认为这并不是我正在寻找的......

Answer 1

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

和

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. 

所以一般来说，是的，您可以使用 Content-Location 标头来识别源资源。使用扩展名后缀的主要缺点是您要创建另一个 URL，例如 /users/bob、/users/bob.vfc、/users/bob.html 是三个不同的资源。