Question

前言

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

这就是现实slaps you in the face。

因此，为了帮助浏览器（以及您自己尝试调试）强制服务以提供所需的内容类型，您可以做每个自尊的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>。

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

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

Answer 1

据我所知，你使用Content-Location的方式完全错误;它应该指向更具体的URI。

Answer 2

根据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标头来标识原始资源。使用扩展名后缀的主要缺点是您要制作其他网址，例如/ users / bob，/ users / bob.vfc，/ users / bob.html是三种不同的资源。

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

2 个答案: