当底层资源不允许 GET 时使用 HTTP HEAD 方法

Question

我们有一个支持超链接的 REST API。通过我们的自动化测试，我们可以遍历响应中的所有链接，并检查它们是否正确，即实际可访问。为此，我们目前使用 HEAD HTTP 方法。现在，规范指出HEAD的行为基本上应该像GET一样，但没有主体。目前为止，一切都好。

但是，我们也有一些端点只支持 DELETE 或 PUT，而不支持 GET。

问题是：如果我们也使用 HEAD 检查这些端点，它是否仍然有效 HTTP - 或者甚至有意义？当然，在这种情况下不应该有任何副作用，测试的目的基本上只是：">端点，你还活着并且可以到达吗"？

任何想法(或者可能是替代方案(？

Answer 1

问题是：如果我们也使用 HEAD 检查这些端点，它是否仍然有效 HTTP - 或者甚至有意义？

是的，这是完全有道理的。

405 方法不允许是您在这里的盟友，它为您提供了一种区分不可读资源和没有表示的资源的方法 (404(。

广泛的原则是，在 REST 中，所有资源都以相同的方式理解相同的方法。 因此，HEAD始终是一个合理的选择。

也就是说，您可能需要查看 OPTIONS，它与 HEAD 一样也是安全的，旨在允许您查询给定资源支持哪些方法。