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

Question

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

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

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

有什么想法（或替代方案）？

标签： resthttphttp-headers

Answer 1

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

是的，这很有意义。

405 Method Not Allowed是你的盟友，它为你提供了一种方法来区分不可读的资源和没有表示的资源 (404)。

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

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