为什么HTTP位置标头只为POST请求/201（创建）响应设置？

Question

暂时忽略3xx响应，我想知道为什么HTTP location标头仅与POST requests/201（Created）响应结合使用。

从 RFC2616规范:

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

这是一个广泛支持的行为，但为什么不应该与其他HTTP方法一起使用？以 JSON API规范 作为一个例子:

它定义了JSON有效负载中当前资源的自引用链接（对于RESTful Api来说并不罕见).此链接包含在每个有效负载中。规范说你 必须 包括一个HTTP位置标头，如果您通过POST创建一个新文档，并且该值与有效负载中的自引用链接相同，但这是 只有 岗位所需。何必与一个 海关规定 自引用链接的格式，如果您可以使用HTTP位置标头？

注:这不是特定于JSON API。这是一样的 哈尔, JSON超架构 或其他标准。

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

我不想咆哮，它似乎只是某种"重新发明轮子"。它似乎也非常有限:如果您只使用HTTP location/link标头，那么如果您在HTTP accept标头中要求JSON，XML或任何内容，并且您将在HEAD请求中获得有关资源的有用元信息，如果您使用JSON API，HAL或JSON Hyper-Schema，

Answer 1

的语义 Location 标头不是自引用链接的标头，而是用户代理应该遵循的链接以完成请求。这在重定向中是有意义的，当您创建一个新资源将位于您应该转到的新位置时。如果你的请求已经完成，这意味着你已经有了你想要的资源的完整表示，那么返回一个 Location.

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

资源表示中对自定义链接格式的需求是将资源与底层实现和协议解耦的固有需求。REST不耦合到HTTP，并且可以使用任何具有有效URI方案的协议。如果你决定使用 Link 所有链接的头，你耦合到HTTP。

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

Answer 2

位置头的语义取决于状态代码。对于201，它链接到新创建的资源，但在3xx请求中，它可以具有多个（虽然类似）。我认为这就是为什么它通常避免用于其他用法。

替代方案是内容位置标题，总是具有一致的含义。它讲述了客户端请求的资源的规范URL。它纯粹是信息（与该位置相比，预期由客户处理的位置）。

所以，内容 - 位置标题似乎更靠近自引用链接。但是，内容 - 位置也有没有定义Put和Post 的行为。似乎也很少使用。

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

最后，任何标题都不适用于通用链接。

总和，需要标准化的，身体的自我链接似乎是好主意。它避免了客户端的很多混淆。