我正在设置一个 REST Web 服务，它只需要尽快回答“是”或“否”。
设计 HEAD 服务似乎是最好的方法，但我想知道与执行 GET 请求相比，我是否真的能获得一些时间。
我想我获得了不会在我的服务器上打开/关闭的正文流（大约 1 毫秒？）。由于返回的字节数非常少，我是否在传输中获得任何时间，在 IP 数据包数中？
提前感谢您的回复！
编辑：
为了进一步解释上下文：
由于最后一个服务会经常被大量客户端调用（预计每 5 毫秒调用一次），我想知道使用 HEAD 方法是否可以进行有价值的优化？响应正文中返回大约 250 个字符。HEAD 方法至少获得了这 250 个字符的传输，但那有什么影响呢？
我试图对这两种方法（HEAD 与 GET）之间的差异进行基准测试，运行 1000 次调用，但根本看不到任何增益（< 1ms）......
RESTful URI 应该代表服务器上的“资源”。资源通常存储为数据库中的记录或文件系统上的文件。除非资源很大或在服务器上检索的速度很慢，否则您可能看不到使用HEAD而不是GET. 可能是检索元数据并不比检索整个资源快。
您可以实现这两个选项并对它们进行基准测试以查看哪个更快，但我不会进行微优化，而是专注于设计理想的 REST 接口。从长远来看，干净的 REST API 通常比可能更快也可能不会更快的杂乱无章的 API 更有价值。我并不反对使用HEAD，只是建议您仅在“正确”设计时才使用它。
如果您需要的信息确实是关于可以在 HTTP 标头中很好地表示的资源的元数据，或者检查资源是否存在，则HEAD可能会很好地工作。
例如，假设您要检查资源 123 是否存在。A200表示“是”，a404表示“否”：
HEAD /resources/123 HTTP/1.1
[...]
HTTP/1.1 404 Not Found
[...]
但是，如果您希望 REST 服务的“是”或“否”是资源本身的一部分，而不是元数据，则应使用GET.
在寻找请求者提出的相同问题时，我发现了这个回复。我还在http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html找到了这个：
HEAD 方法与 GET 相同，只是服务器不能在响应中返回消息体。响应 HEAD 请求的 HTTP 标头中包含的元信息应该与响应 GET 请求发送的信息相同。此方法可用于获取有关请求所隐含的实体的元信息，而无需传输实体主体本身。这种方法通常用于测试超文本链接的有效性、可访问性和最近的修改。
在我看来，对请求者问题的正确答案是它取决于 REST 协议所代表的内容。例如，在我的特定情况下，我的 REST 协议用于检索相当大（如超过 10K）的图像。如果我经常检查大量此类资源，并且考虑到我使用了请求标头，那么根据 w3.org 的建议，使用 HEAD 请求是有意义的。
GET 获取头部 + 身体，HEAD 只获取头部。哪个更快不应该是一个意见问题。我不明白上面赞成的答案。如果您正在寻找 META 信息，请选择 HEAD，它就是为此目的。
我强烈反对这种方法。
RESTful 服务应该尊重 HTTP 动词语义。GET 动词用于检索资源的内容，而 HEAD 动词不会返回任何内容，可用于例如查看资源是否已更改、了解其大小或类型、检查它是否存在，等等。
请记住：早期优化是万恶之源。
使用 HEAD 请求而不是 GET 请求几乎不会改变您的性能。
此外，当您希望它是 REST-ful 并且想要获取数据时，您应该使用 GET 请求而不是 HEAD 请求。
HEAD请求就像GET请求，只是响应的主体是空的。当您只需要有关文件的元数据但不需要传输文件的所有数据时，可以使用这种请求。
我不明白您对“身体流被打开/关闭”的担忧。响应正文将位于与 http 响应标头相同的流上，并且不会创建第二个连接（顺便说一下，该连接更多在 3-6 毫秒的范围内）。
这似乎是一种非常不成熟的优化尝试，它不会产生显着甚至可测量的差异。真正的区别是总体上与 REST 的一致性，它建议使用 GET 来获取数据。
我的回答是否定的，如果有意义就使用 GET，使用 HEAD 不会提高性能。
您可以轻松地进行一个小测试来自己衡量性能。我认为性能差异可以忽略不计，因为如果您只在正文中返回“Y”或“N”，则它是附加到已经打开的流的一个额外字节。
我也会选择 GET，因为它更正确。您不应该返回 HTTP 标头中的内容，只返回元数据。