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