json - 为什么仅为 POST 请求/201(已创建)响应设置 HTTP 位置 header ？

Question

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

来自 RFC 2616 spec :

For 201 (Created) responses, the Location is that of the new resource which was created by the request.

这是一种广泛支持的行为，但为什么不应该将它与其他 HTTP 方法一起使用呢？拍 JSON API spec举个例子:

它为 JSON 有效负载 ( not uncommon for RESTful APIs ) 中的当前资源定义了一个自引用链接。此链接包含在每个有效负载中。规范说你 必须 如果您通过 POST 创建新文档并且该值与有效负载中的自引用链接相同，则包含 HTTP 位置 header ，但这是 仅限 POST 需要。如果您可以只使用 HTTP 位置 header ，为什么还要为自引用链接使用自定义格式？

注意:这并不特定于 JSON API。 HAL 也一样, JSON Hyper-Schema或其他标准。

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

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

Answer 1

Location 的语义 header 不是自引用链接，而是用户代理应该遵循的链接以完成请求。这在重定向中是有意义的，当您创建将在新位置的新资源时，您应该去。如果您的请求已经完成，这意味着您已经拥有所需资源的完整表示，则返回 Location 是没有意义的。 .
Link header 可能被认为在语义上等同于超文本链接，但当媒体类型不支持超媒体时，它应该用于引用与给定资源相关的元数据，因此它不会取代链接中相关资源的功能一个 RESTful API。

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

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