暂时忽略3xx响应，我想知道为什么HTTP位置标头仅与POST请求/ 201（创建）响应一起使用。
对于201（已创建）响应，该位置是由请求创建的新资源的位置。
这是一种受到广泛支持的行为，但为什么不应该将其与其他HTTP方法一起使用？以JSON API spec为例：
它为JSON有效负载（not uncommon for RESTful APIs）内的当前资源定义了自引用链接。此链接包含在每个有效负载中。规范说你必须包含一个HTTP位置标题，如果你通过POST创建一个新文档，并且该值与有效负载中的自引用链接相同，但这只是 ONLY 需要POST。如果你可以使用HTTP位置标题，为什么还要为自引用链接使用自定义格式呢？
注意：这不是特定于JSON API的。 HAL，JSON Hyper-Schema或其他标准也是如此。
注2：它甚至不特定于HTTP位置标头，因为它与HTTP链接标头相同。正如您所看到的，JSON API，HAL和JSON Hyper-Schema不仅定义了自引用链接的约定，还表达了有关资源的相关资源或可能的操作的信息。但似乎他们都可以使用HTTP链接头。 （如果他们不想使用HTTP位置标头，他们甚至可以将自引用链接放入HTTP链接头。）
我不想咆哮，它似乎只是某种＆＃34;重新发明轮子＆＃34;。它似乎也是非常有限的：如果你只是使用HTTP位置/链接头，那么如果你在HTTP接受头中要求JSON，XML或其他任何内容并不重要，那么你将获得有关你的有用的元信息HEAD请求上的资源，如果您使用JSON API，HAL或JSON Hyper-Schema，则不会包含链接。
答案 0 :(得分：6)
Location标头的语义不是自引用链接的语义，而是用户代理应该遵循的链接以完成请求。这在重定向中是有意义的，当您创建一个将位于新位置的新资源时，您应该去。如果您的请求已经完成，这意味着您已经拥有所需资源的完整代表，那么返回Location是没有意义的。
Link标头可以被认为在语义上等同于超文本链接，但是当媒体类型不是超媒体感知时，它应该用于引用与给定资源相关的元数据，因此它不会替换RESTful API中相关资源链接的功能。
在资源表示中需要自定义链接格式是将资源与底层实现和协议分离的必要条件。 REST不与HTTP耦合，可以使用任何有效URI方案的协议。如果您决定对所有链接使用Link标头，那么您将耦合到HTTP。
假设您提供了一个FTP链接供客户关注。在这种情况下，Link会在哪里？
答案 1 :(得分：5)
Location头的语义取决于状态代码。对于201，它链接到新创建的资源，但在3xx请求中它可以具有多个（尽管类似的）含义。我认为这就是为什么通常会避免其他用法。
替代方案是Content-Location标头，它始终具有一致的含义。它告诉客户端规范URL所请求的资源。它纯粹是信息性的（与位置相反，预计将由客户处理）。
因此，Content-Location标题看起来更像是一个自引用链接。但是，内容位置也有no defined behavior for PUT and POST。它似乎也很少使用。
此博客文章Location vs Content-Location是一个很好的比较。这是一个引用：
最后，两个标题都不适用于通用链接。
总而言之，要求身体中的标准化，自我链接似乎是个好主意。它避免了客户端的很多混乱。