5

前言：

在阅读了大量有关 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>.

有没有我错过的陷阱？这有什么优点/缺点？

编辑：这让我注意到有点晚了。即使它触及主题并且真的很有帮助，我认为这并不是我想要的......

4

2 回答 2

1

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

于 2013-04-09T05:35:37.827 回答
0

根据 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 是三种不同的资源。

于 2013-04-08T15:46:33.183 回答