http - 我应该这样使用 Content-Location header 吗？

Question

前言:

在阅读了大量有关 HTTP 和 REST 的内容后，您花了几个小时设计了一个巧妙的内容协商方案。这样您的 Web API 就可以从单个 URL 提供 XML、JSON 和 HTML。因为，您知道，一项资源应该只有一个 URL，并且应该使用 Accept 请求不同的表示形式。标题。您开始想知道为什么网络花了 20 年才实现这一点。

那就是现实slaps you in the face .

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

尽管在 hell 中受到永恒的折磨，以下是对 Content-Location 的使用+ .ext可以接受吗？

假设我们在 /users/:loginname 有用户例如 /users/bob .这将是任何能够设置适当 Accept 的 API 端点。 header 。但是对于任何可能的 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。