metodos - http HEAD vs GET rendimiento

metodos http (7)

Estoy configurando un servicio web REST que solo necesita responder SÍ o NO, tan rápido como sea posible.

Diseñar un servicio HEAD parece ser la mejor manera de hacerlo, pero me gustaría saber si realmente ganaré algo de tiempo en lugar de hacer una solicitud GET.

Supongo que obtengo la corriente del cuerpo para no abrir / cerrar en mi servidor (¿aproximadamente 1 milisegundo?). Dado que la cantidad de bytes para devolver es muy baja, ¿obtengo algún tiempo de transporte, en el número de paquete IP?

¡Gracias por adelantado por tu respuesta!

Editar:

Para explicar más el contexto:

Tengo un conjunto de servicios REST ejecutando algunos procesos, si están en un estado activo.
Tengo otro servicio REST que indica el estado de todos estos primeros servicios.

Como ese último servicio será llamado muy a menudo por un gran grupo de clientes (se espera una llamada cada 5 ms), me preguntaba si usar un método HEAD puede ser una optimización valiosa. Se devuelven unos 250 caracteres en el cuerpo de respuesta. El método HEAD al menos gana el transporte de estos 250 caracteres, pero ¿qué impacto tiene?

Traté de comparar la diferencia entre los dos métodos (HEAD vs GET), ejecutando 1000 veces las llamadas, pero no veo ninguna ganancia (<1ms) ...

Desanimo firmemente este tipo de enfoque.

Un servicio RESTful debe respetar la semántica de los verbos HTTP. El verbo GET está destinado a recuperar el contenido del recurso, mientras que el verbo HEAD no devolverá ningún contenido y puede usarse, por ejemplo, para ver si un recurso ha cambiado, para conocer su tamaño o su tipo, para verificar si existe, y así sucesivamente.

Y recuerda: la optimización temprana es la raíz de todo mal.

Encontré esta respuesta cuando buscaba la misma pregunta que el solicitante. También encontré esto en http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html :

El método HEAD es idéntico a GET, excepto que el servidor NO DEBE devolver un cuerpo del mensaje en la respuesta. La metainformación contenida en los encabezados HTTP en respuesta a una solicitud HEAD DEBERÍA ser idéntica a la información enviada en respuesta a una solicitud GET. Este método se puede usar para obtener metainformación sobre la entidad implicada por la solicitud sin transferir el cuerpo de la entidad en sí. Este método se usa a menudo para probar enlaces de hipertexto para determinar su validez, accesibilidad y modificaciones recientes.

Me parece que la respuesta correcta a la pregunta del solicitante es que depende de lo que representa el protocolo REST. Por ejemplo, en mi caso particular, mi protocolo REST se usa para recuperar imágenes bastante grandes (como en más de 10K). Si tengo una gran cantidad de dichos recursos que se revisan de manera constante, y dado que uso los encabezados de solicitud, entonces tendría sentido utilizar la solicitud HEAD, según las recomendaciones de w3.org.

GET capta cabeza + cuerpo, HEAD capta cabeza solamente. No debería ser una cuestión de opinión cuál es más rápido. No entiendo las respuestas arriba expuestas. Si está buscando información META que ir por HEAD, que es para este propósito.

No entiendo su preocupación por la ''corriente corporal abierta / cerrada''. El cuerpo de respuesta estará sobre el mismo flujo que los encabezados de respuesta http y NO creará una segunda conexión (que por cierto está más en el rango de 3-6ms).

Esto parece un intento de optimización muy precoz en algo que simplemente no hará una diferencia significativa o incluso mensurable. La diferencia real es la conformidad con REST en general, que recomienda usar GET para obtener datos.

Mi respuesta es NO, use GET si tiene sentido, no hay ganancia de rendimiento con HEAD.

Puede hacer fácilmente una pequeña prueba para medir el rendimiento usted mismo. Creo que la diferencia de rendimiento sería insignificante, ya que si solo devuelve ''S'' o ''N'' en el cuerpo, se agregará un byte adicional a una secuencia ya abierta.

También iría con GET ya que es más correcto. Se supone que no debes devolver contenido en encabezados HTTP, solo metadatos.

Su rendimiento apenas cambiará al usar una solicitud HEAD en lugar de una solicitud GET.

Además, cuando desee que sea REST -ful y desee OBTENER datos, deberá utilizar una solicitud GET en lugar de una solicitud HEAD.

Un URI RESTful debe representar un "recurso" en el servidor. Los recursos a menudo se almacenan como un registro en una base de datos o un archivo en el sistema de archivos. A menos que el recurso sea grande o demore su recuperación en el servidor, es posible que no vea una ganancia medible al usar HEAD lugar de GET . Podría ser que recuperar los metadatos no sea más rápido que recuperar el recurso completo.

Podría implementar ambas opciones y compararlas para ver cuál es más rápido, pero en lugar de micro optimizar, me centraría en diseñar la interfaz REST ideal. Una API REST limpia suele ser más valiosa a largo plazo que una API kludgey que puede o no ser más rápida. No estoy desalentando el uso de HEAD , solo sugiero que solo lo use si es el diseño "correcto".

Si la información que realmente necesita es metadatos sobre un recurso que puede representarse bien en los encabezados HTTP, o para verificar si el recurso existe o no, HEAD podría funcionar bien.

Por ejemplo, supongamos que desea verificar si el recurso 123 existe. Un 200 significa "sí" y un 404 significa "no":

HEAD /resources/123 HTTP/1.1 [...] HTTP/1.1 404 Not Found [...]

Sin embargo, si el "sí" o el "no" que desea de su servicio REST es una parte del recurso en sí, en lugar de metadatos, debe usar GET .