5

暂时忽略 3xx 响应，我想知道为什么 HTTP 位置标头仅与 POST 请求/201（已创建）响应一起使用。

来自RFC 2616 规范：

对于 201（已创建）响应，位置是请求创建的新资源的位置。

这是一种广泛支持的行为，但为什么不应该将它与其他 HTTP 方法一起使用呢？以JSON API 规范为例：

它为 JSON 有效负载中的当前资源定义了一个自引用链接（对于 RESTful API 来说并不少见）。此链接包含在每个有效负载中。规范说，如果您通过 POST 创建新文档并且该值与有效负载中的自引用链接相同，则必须包含 HTTP 位置标头，但这仅在 POST 中需要。如果您可以只使用 HTTP 位置标头，为什么还要为自引用链接使用自定义格式？

注意：这并不特定于 JSON API。HAL、JSON Hyper-Schema或其他标准也是如此。

注意 2：它甚至不是特定于 HTTP 位置标头，因为它与 HTTP 链接标头相同。如您所见，JSON API、HAL 和 JSON Hyper-Schema 不仅定义了自引用链接的约定，还表达了有关资源的相关信息或资源的可能操作。但似乎他们都可以只使用 HTTP 链接头。（如果他们不想使用 HTTP 位置标头，他们甚至可以将自引用链接放入 HTTP 链接标头。）

我不想咆哮，这似乎是某种“重新发明轮子”。它似乎也非常有限：如果您只使用 HTTP 位置/链接标头，那么您是否在 HTTP 接受标头中要求 JSON、XML 或任何内容都没有关系，您将获得有关您的资源的有用元信息一个 HEAD 请求，如果您使用 JSON API、HAL 或 JSON Hyper-Schema，它将不包含链接。

4

2 回答 2

8

标头的语义Location不是自引用链接的语义，而是用户代理应该遵循的链接以完成请求。这在重定向中是有意义的，当您创建将在新位置的新资源时，您应该去。如果您的请求已经完成，这意味着您已经拥有所需资源的完整表示，则返回Location.

标Link头可能被认为在语义上等同于超文本链接，但当媒体类型不支持超媒体时，它应该用于引用与给定资源相关的元数据，因此它不会取代指向相关资源的链接的功能在 RESTful API 中。

资源表示中对自定义链接格式的需求是资源与底层实现和协议分离的内在需求。REST 不与 HTTP 耦合，任何具有有效 URI 方案的协议都可以使用。如果您决定Link对所有链接使用标头，那么您将耦合到 HTTP。

假设您为客户提供了一个 FTP 链接。Link在那种情况下会在哪里？

于 2014-06-04T16:31:23.753 回答
6

Location 标头的语义取决于状态码。对于 201，它链接到新创建的资源，但在 3xx 请求中它可以有多个（尽管相似）含义。我认为这就是为什么它通常被避免用于其他用途。

另一种方法是 Content-Location 标头，它始终具有一致的含义。它告诉客户端它所请求的资源的规范 URL。它纯粹是提供信息的（与预计由客户端处理的位置相反）。

因此，Content-Location 标头似乎更类似于自引用链接。但是，Content-Location 也没有为 PUT 和 POST 定义行为。它似乎也很少使用。

这篇博客文章位置与内容位置是一个很好的比较。这是一个报价：

最后，这两个标头都不适用于通用链接。

总之，在正文中要求一个标准化的自我链接似乎是个好主意。它避免了客户端的很多混乱。

于 2014-06-04T22:49:12.430 回答