Http HEAD vs GET 性能

小开

使用 HEAD 请求而不是 GET 请求几乎不会改变性能。

此外，当您希望它是 REST-ful 并且希望获取数据时，应该使用 GET 请求而不是 HEAD 请求。

小开

您可以很容易地做一个小测试来测量自己的性能。我认为这种性能差异可以忽略不计，因为如果只在主体中返回‘ Y’或‘ N’，那么就是在已经打开的流中附加了一个额外的字节。

我还建议使用 GET，因为它更正确。您不应该返回 HTTP 头中的内容，只能返回元数据。

小开

最佳答案

RESTful URI 应该表示服务器上的“资源”。资源通常作为记录存储在数据库或文件系统中。除非资源很大或者在服务器上检索速度很慢，否则使用 HEAD而不是 GET可能无法获得可测量的收益。可能检索元数据并不比检索整个资源快。

您可以实现这两个选项并对它们进行基准测试，以确定哪一个更快，但是我将关注于设计理想的 REST 接口，而不是进行微优化。从长远来看，一个干净的 REST API 通常比一个可能更快，也可能不更快的 kudgey API 更有价值。我并不是不鼓励使用 HEAD，只是建议您只有在“正确”的设计时才使用它。

如果您真正需要的信息是关于资源的元数据，这些元数据可以很好地在 HTTP 头中表示，或者检查资源是否存在，那么 HEAD可能会很好地工作。

例如，假设您想检查资源123是否存在，200表示“是”，而 404表示“否”:

HEAD /resources/123 HTTP/1.1
[...]


HTTP/1.1 404 Not Found
[...]

但是，如果您希望从 REST 服务中得到的“是”或“否”是资源本身的一部分，而不是元数据，那么您应该使用 GET。

小开

我不明白你为什么关心“身体流是否打开/关闭”。响应主体将通过与 http 响应头相同的流，并且不会创建第二个连接(顺便说一下，这个连接在3-6ms 的范围内)。

这似乎是一个非常不成熟的优化尝试，只是不会产生重大甚至可测量的差异。真正的区别在于通常与 REST 的一致性，后者建议使用 GET 获取数据。.

我的答案是否定的，如果使用 GET 有意义的话，那么使用 HEAD 不会有任何性能提升。

小开

我强烈反对这种做法。

RESTful 服务应该尊重 HTTP 动词的语义。GET 谓词用于检索资源的内容，而 HEAD 谓词不会返回任何内容，例如，可以用于查看资源是否已经更改，了解其大小或类型，检查它是否存在，等等。

记住: 早期优化是万恶之源。

小开

我在寻找请求者提出的同一个问题时发现了这个答案，我也在 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html上发现了这个:

HEAD 方法与 GET 相同，只是服务器不能在响应中返回消息体。响应 HEAD 请求的 HTTP 头中包含的元信息应该与响应 GET 请求发送的信息相同。此方法可用于获取关于请求所隐含的实体的元信息，而无需传输实体本身。此方法通常用于测试超文本链接的有效性、可访问性和最近的修改。

在我看来，请求者问题的正确答案是，它取决于 REST 协议所表示的内容。例如，在我的特殊情况下，我的 REST 协议用于检索相当大的(如超过10K)图像。如果我有大量这样的资源在不断地被检查，并且我使用了请求头，那么根据 w3.org 的建议，使用 HEAD 请求是有意义的。

小开

GET 取头 + 身，头只取头。这不应该是看哪个更快的问题。我不明白上面的反对意见。如果你正在寻找的 META 信息，比去 HEAD，这是为了这个目的。

小开

HEAD 请求与走开请求类似，只不过响应的主体是空的。当您需要的只是关于文件的元数据，而不需要传输文件的所有数据时，可以使用此类请求。