我正在设置一个REST Web服务,只需要尽快回答"是"或"否".
设计HEAD服务似乎是最好的方法,但我想知道我是否真的会比做GET请求获得一些时间.
我想我的身体流不能在我的服务器上打开/关闭(大约1毫秒？).由于要返回的字节数非常少,我是否可以在传输中获得IP数据包的任何时间？
在此先感谢您的回复!
编辑:
进一步解释上下文:
由于最后一个服务将经常被一组非常大的客户端调用(每隔5ms调用一次),我想知道使用HEAD方法是否可以进行有价值的优化？响应正文中返回约250个字符.HEAD方法至少可以获得这250个字符的传输,但这有什么影响呢？
我尝试对两种方法(HEAD与GET)之间的差异进行基准测试,运行1000次调用,但看不到任何增益(<1ms)......
And*_*e D 153
RESTful URI应代表服务器上的"资源".资源通常存储为数据库中的记录或文件系统上的文件.除非资源很大或者在服务器上检索速度很慢,否则您可能无法通过使用HEAD代替来获得可衡量的增益GET.可能是检索元数据并不比检索整个资源快.
您可以实现这两个选项并对它们进行基准测试以查看哪个更快,而不是微优化,我将专注于设计理想的REST接口.从长远来看,干净的REST API通常比可能更快或更快的kludgey API更有价值.我并不劝阻HEAD使用它,只是建议你只使用它,如果它是"正确的"设计.
如果您需要的信息确实是关于可以在HTTP标头中很好地表示的资源的元数据,或者检查资源是否存在,HEAD那么可能会很好地工作.
例如,假设您要检查资源123是否存在.A 200表示"是",404表示"否":
HEAD /resources/123 HTTP/1.1
[...]
HTTP/1.1 404 Not Found
[...]
但是,如果您希望REST服务中的"是"或"否"是资源本身的一部分,而不是元数据,则应使用GET.
小智 35
在寻找请求者提出的相同问题时,我找到了这个回复.我也在http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html上找到了这个:
HEAD方法与GET相同,只是服务器不能在响应中返回消息体.响应HEAD请求的HTTP头中包含的元信息应该与响应GET请求时发送的信息相同.该方法可用于获得关于请求所暗示的实体的元信息,而无需转移实体主体本身.此方法通常用于测试超文本链接的有效性,可访问性和最近的修改.
在我看来,请求者问题的正确答案是它取决于REST协议所代表的内容.例如,在我的特定情况下,我的REST协议用于检索相当大的(如超过10K)图像.如果我不断检查大量此类资源,并且考虑到我使用了请求标头,那么根据w3.org的建议使用HEAD请求是有意义的.
Eri*_*ire 12
我强烈反对这种做法.
RESTful服务应该尊重HTTP动词语义.GET动词用于检索资源的内容,而HEAD动词不会返回任何内容,例如,可以用于查看资源是否已更改,以了解其大小或类型,以检查是否存在,等等.
请记住:早期优化是万恶之源.
GET获取head + body，HEAD仅获取head。哪一个更快是不应该的。我不理解上面提出的答案。如果您要查找META信息而不是HEAD，则是为此目的。
HEAD请求就像GET请求一样，除了响应的主体是空的。当您只需要有关文件的元数据但不需要传输文件的所有数据时，可以使用这种请求。