Performances de http HEAD vs GET

Question

Je suis en train de mettre en place un service web REST qui doit simplement répondre par OUI ou NON, aussi vite que possible.

La conception d'un service HEAD semble être la meilleure façon de procéder, mais j'aimerais savoir si je vais vraiment gagner du temps par rapport à une requête GET.

Je suppose que j'obtiens que le flux de corps ne soit pas ouvert/fermé sur mon serveur (environ 1 milliseconde ?). Comme le nombre d'octets à renvoyer est très faible, est-ce que je gagne du temps dans le transport, dans le nombre de paquets IP ?

Merci d'avance pour votre réponse !

Edit :

Pour expliquer davantage le contexte :

• J'ai un ensemble de services REST qui exécutent certains processus, s'ils sont dans un état actif.
• J'ai un autre service REST qui indique l'état de tous ces premiers services.

Comme ce dernier service sera appelé très souvent par un très grand nombre de clients (un appel prévu toutes les 5 ms), je me demandais si l'utilisation d'une méthode HEAD pouvait constituer une optimisation intéressante ? Environ 250 caractères sont renvoyés dans le corps de la réponse. La méthode HEAD permet au moins de gagner le transport de ces 250 caractères, mais quel est cet impact ?

J'ai essayé d'évaluer la différence entre les deux méthodes (HEAD vs GET), en effectuant 1000 fois les appels, mais je ne vois aucun gain (< 1ms)...

Answer 1

Un URI RESTful doit représenter une "ressource" au niveau du serveur. Les ressources sont souvent stockées comme un enregistrement dans une base de données ou un fichier sur le système de fichiers. À moins que la ressource ne soit volumineuse ou que sa récupération soit lente sur le serveur, vous ne verrez pas de gain mesurable en utilisant l'option HEAD au lieu de GET . Il se peut que la récupération des métadonnées ne soit pas plus rapide que la récupération de la ressource entière.

Vous pouvez mettre en œuvre les deux options et les comparer pour voir laquelle est la plus rapide, mais plutôt que de procéder à une micro-optimisation, je me concentrerais sur la conception de l'interface REST idéale. Une API REST propre a généralement plus de valeur à long terme qu'une API maladroite qui peut ou non être plus rapide. Je ne décourage pas l'utilisation d'une HEAD Je vous suggère simplement de ne l'utiliser que s'il s'agit du "bon" modèle.

Si les informations dont vous avez besoin sont vraiment des méta-données sur une ressource qui peuvent être représentées joliment dans les en-têtes HTTP, ou pour vérifier si la ressource existe ou non, HEAD pourrait très bien fonctionner.

Par exemple, supposons que vous voulez vérifier si la ressource 123 existe. A 200 signifie "oui" et un 404 signifie "non" :

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

HTTP/1.1 404 Not Found
[...]

Toutefois, si le "oui" ou le "non" que vous souhaitez obtenir de votre service REST fait partie de la ressource elle-même, plutôt que des métadonnées, vous devez utiliser la méthode suivante GET .

Answer 2

J'ai trouvé cette réponse en cherchant la même question que celle posée par le demandeur. J'ai également trouvé ceci à http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html :

La méthode HEAD est identique à GET, sauf que le serveur NE DOIT PAS renvoyer de corps de message dans la réponse. Les méta-informations contenues dans les en-têtes HTTP en réponse à une requête HEAD DOIVENT être identiques aux informations envoyées en réponse à une requête GET. Cette méthode peut être utilisée pour obtenir des métainformations sur l'entité impliquée par la demande sans transférer le corps de l'entité lui-même. Cette méthode est souvent utilisée pour tester la validité, l'accessibilité et les modifications récentes des liens hypertextes.

Il me semble que la réponse correcte à la question du demandeur est que cela dépend de ce qui est représenté par le protocole REST. Par exemple, dans mon cas particulier, mon protocole REST est utilisé pour récupérer des images assez grandes (plus de 10 000). Si j'ai un grand nombre de ressources de ce type qui sont vérifiées en permanence, et étant donné que j'utilise les en-têtes de la requête, il serait logique d'utiliser la requête HEAD, conformément aux recommandations de w3.org.

Answer 3

Je déconseille fortement ce genre d'approche.

Un service RESTful doit respecter la sémantique des verbes HTTP. Le verbe GET est destiné à récupérer le contenu de la ressource, tandis que le verbe HEAD ne renvoie aucun contenu et peut être utilisé, par exemple, pour voir si une ressource a été modifiée, pour connaître sa taille ou son type, pour vérifier si elle existe, etc.

Et n'oubliez pas : l'optimisation précoce est la racine de tous les maux.

Answer 4

Vos performances ne changeront guère en utilisant une requête HEAD au lieu d'une requête GET.

En outre, lorsque vous souhaitez que le système soit compatible avec REST et que vous souhaitez obtenir des données, vous devez utiliser une requête GET plutôt qu'une requête HEAD.

Answer 5

Je ne comprends pas votre préoccupation concernant le "courant corporel ouvert/fermé". Le corps de la réponse passera par le même flux que les en-têtes de la réponse http et ne créera PAS de seconde connexion (qui, soit dit en passant, est plutôt de l'ordre de 3 à 6 ms).

Cela ressemble à une tentative d'optimisation prématurée sur quelque chose qui ne fera pas une différence significative ou même mesurable. La vraie différence est la conformité avec REST en général, qui recommande d'utiliser GET pour obtenir des données

Ma réponse est NON, utilisez GET si cela a un sens, il n'y a pas de gain de performance en utilisant HEAD.