http TÊTE contre performance

Je suis à la mise en place d'un service web REST qu'suffit de répondre OUI ou NON, aussi vite que possible.

De la conception d'un CHEF de service me semble la meilleure façon de le faire mais je voudrais savoir si je vais vraiment gagner du temps contre de faire une requête GET.

Je suppose que je gagne le flux de corps de ne pas être ouvert/fermé sur mon serveur (environ 1 milliseconde?).
Puisque la quantité d'octets de retour est très faible, ne je gagne tout le temps dans les transports, dans des paquets IP nombre?

Merci d'avance pour votre réponse!

Edit:

Explique le contexte:

  • J'ai un ensemble de services RESTE l'exécution de certains processus, si elles sont dans un état actif.
  • J'ai un autre service REST indiquant l'état de tous ces premiers services.

Depuis le dernier service sera appelé très souvent par un ensemble très large de clients (un appel prévu toutes les 5ms), je me demandais si à l'aide d'une TÊTE de méthode peut être un facteur d'optimisation? Environ 250 caractères sont retournés dans le corps de la réponse. TÊTE de méthode au moins de gain que le transport de ces 250 caractères, mais qu'est-ce que cet impact?

J'ai essayé de comparer la différence entre les deux méthodes (TÊTE vs GET), cours d'exécution 1000 fois les appels, mais voir aucun gain (< 1ms)...

  • Il dépend aussi de l'approche que vous utilisez côté serveur. Habituellement, il peut prendre le même serveur de temps pour traiter une demande ou une requête HEAD, parce que le serveur puisse avoir besoin de connaître le corps final pour calculer la Content-Length valeur d'en-tête, ce qui est une information importante dans une réponse d'un CHEF de demande. À moins qu'il y est quelques autres plus optimisé approche côté serveur, le seul avantage est que la bande passante est enregistré, et le client n'a pas à analyser le corps de la réponse. Donc, fondamentalement, l'optimisation des gains dépendent à la fois de serveur et de l'implémentation du client.
InformationsquelleAutor Asterius | 2013-05-14
  1. 145

    Une bonne URI devrait représenter une "ressource" sur le serveur. Les ressources sont souvent stockés comme un enregistrement dans une base de données ou un fichier sur le système de fichiers. À moins que la ressource est importante ou est lent à récupérer sur le serveur, vous pourriez ne pas voir un gain mesurable en utilisant HEAD au lieu de GET. Il se pourrait que récupérer les méta-données, est pas plus vite que la récupération de la totalité de la ressource.

    Vous pourriez mettre en œuvre les deux options, et de les comparer pour voir qui est plus rapide, mais plutôt que de micro-optimisation, je me concentrerais sur la conception de l'idéal RESTE de l'interface. Propre API REST est généralement plus précieux dans le long terme que d'un kludgey API qui peut ou ne peut pas être plus rapide. Je ne suis pas en décourageant l'utilisation de HEAD, juste ce qui suggère que vous ne l'utilisez si c'est le "droit" de conception.

    Si les informations que vous avez vraiment besoin est de méta-données sur une ressource qui peut être bien représentés dans les en-têtes HTTP, ou pour vérifier si la ressource existe ou pas, HEAD pourrait fonctionner bien.

    Par exemple, supposons que vous voulez vérifier si la ressource 123 existe. Un 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 "non" vous voulez à partir de votre service de REPOS est une partie de la ressource elle-même, plutôt que de méta-données, vous devez utiliser GET.

    • les meilleures choses sont toujours simples, comme cette réponse. Voila!
    • Magnifique réponse! J'ai une question: Qu'en est au sujet de l'utiliser comme un touch commande pour mettre à jour un post comptent sur le serveur? Les données post a déjà été récupéré via une normale /posts appel, donc, je veux juste mettre à jour le nombre de vues après que l'utilisateur interagit avec le post d'une certaine façon.
    • Si vous voulez mettre à jour un compteur de vue pour HEAD demandes, alors vous devriez le faire pour GET demandes aussi. La décision d'utiliser GET ou HEAD est en fin de compte, le client HTTP. Votre serveur devrait se comporter de la même manière pour les deux types de demande, sauf qu'il n'y est pas le corps de la réponse lors de la réponse à HEAD. Quant à savoir si c'est une bonne façon de mettre en œuvre quelque chose comme un compteur de vue, je ne suis pas sûr.
    • -1 Toute information qui peut être nommé peut être une ressource. Donc Uniform Resource Locator. L'idée que l'utilisation d'une partie du protocole HTTP, comme prévu, est "kludgey" ou "impur" est bizarre.
    • Je ne peux pas faire beaucoup de sens de votre commentaire, mais la farce de données dans les en-têtes HTTP, juste de sorte qu'il peut être récupéré avec un HEAD demande n'est pas en utilisant le protocole tel que conçu.
    • Retour les en-Têtes d'une ressource par tête n'est pas "kludgey", "impur" ou "la farce de données" - dans la Fpo question, ils ont voulu savoir sur les actifs de l'état - ainsi, par exemple, - retour d'un "404" pour les non/non trouvé ou "200" pour oui/découverte pourrait être tout à fait acceptable, aussi à l'aide de "304" Pas Modifiée avec l'Etag en-tête de requête pourrait être une bonne solution - permettant ainsi au client de vérifier simplement si l'état actif a changé depuis qu'il a été vérifié par le client. Tout cela est clairement la manière dont le protocole HTTP est conçu.
    • Vous semblez avoir mal compris ma réponse. À l'aide de 200/404 pour oui/non a ma propre suggestion que je me tiens derrière elle, comme une bonne solution. Si vous souhaitez discuter davantage, veuillez démarrer une conversation.
    • Vous semblez avoir mal compris mon objection.
    • Unless the resource is large or is slow to retrieve at the server, you might not see a measurable gain by using HEAD instead of GET. J'ai un Q. Pour une HEAD appel, de ne pas les ressources doivent être récupérés si grand pas dans le but de calculer Content-length? Donc, à la fois GET et HEAD prendrait le même temps sur le serveur-côté? À moins que le serveur gère pour calculer la longueur du contenu sans une ressource coûteuse-fetch...
    • c'est très souvent vrai, mais pas toujours. Content-Length peut être omis lors de l'utilisation de Transfer-Encoding: chunked. Même avec Content-Length, il est possible que le serveur peut accéder à la ressource de taille et d'autres métadonnées utilisées dans les en-têtes sans aller chercher la ressource réelle. Peut-être que les métadonnées sont encore dans la mémoire cache pour un accès très rapide. C'est très de mise en œuvre spécifiques.
    • Ne pouvait pas avoir demandé plus élaborée répondre, je vous remercie!
    • parfait et simple la réponse!!

    InformationsquelleAutor Andre D
  2. 34

    J'ai trouvé cette réponse lors de la recherche pour la même question que le demandeur a demandé. J'ai également trouvé ce à http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html:

    La TÊTE de la méthode est identique pour les OBTENIR, sauf que le serveur ne DOIT PAS retourner un corps dans la réponse. La meta-information contenue dans l'entête HTTP de la réponse à une requête HEAD DEVRAIT être identique pour les renseignements transmis en réponse à une requête GET. Cette méthode peut être utilisée pour obtenir des métainformations au sujet de l'entité impliquée par la demande sans avoir à transférer le corps de l'entité elle-même. Cette méthode est souvent utilisée pour les tests de liens hypertextes, pour la validité, l'accessibilité et la modification récente.

    Il me semble que la bonne réponse au demandeur de la question est que cela dépend de ce qui est représenté par le RESTE du protocole. Par exemple, dans mon cas particulier, mon REPOS protocole est utilisé pour récupérer assez grand (comme dans plus de 10K) des images. Si j'ai un grand nombre de ces ressources sont vérifiés sur une base constante, et étant donné que j'ai utiliser les en-têtes de requête, alors il serait logique d'utiliser la TÊTE de la demande, par w3.org les recommandations de l'.

    InformationsquelleAutor Charles Thomas
  3. 12

    Je déconseille vivement ce genre d'approche.

    Un service RESTful doit respecter les verbes HTTP sémantique. Le verbe GET est destinée à récupérer le contenu de la ressource, tandis que la TÊTE de verbe ne vous donnera pas de contenu et ne peut être utilisé, par exemple, pour voir si une ressource a changé, à savoir sa taille ou son type, afin de vérifier si elle existe, et ainsi de suite.

    Et souvenez-vous : début de l'optimisation est la racine de tous les maux.

    InformationsquelleAutor Eric Citaire
  4. 7

    Votre performance guère se modifier à l'aide d'un CHEF de demande au lieu d'une requête GET.

    De plus, lorsque vous voulez qu'il soit REST-ful et vous souhaitez OBTENIR les données, vous devez utiliser une requête GET à la place d'un CHEF de demande.

    InformationsquelleAutor jabbink
  5. 5

    OBTENIR des extractions tête + corps, la TÊTE récupère la tête seulement. Il ne devrait pas être une question d'opinion qui est plus rapide. Je ne pas comprendre le upvoted les réponses ci-dessus. Si vous êtes à la recherche pour les MÉTA-informations que d'aller pour la TÊTE, qui est destiné à cette fin.

    InformationsquelleAutor Viktor Joras
  6. 3

    Je ne comprends pas votre préoccupation du corps stream ouvert/fermé". Le corps de la réponse sera sur le même flux que les en-têtes de réponse http et ne sera PAS la création d'une deuxième connexion (qui en passant est plus dans la gamme de 3-6ms).

    Cela semble être une très pré-maturité optimisation de la tentative sur quelque chose qui ne va pas faire une grande ou même différence mesurable. La vraie différence est la conformité avec le REPOS en général, qui recommande l'utilisation de données..

    Ma réponse est NON, l'utilisation, si elle a un sens, il n'y a pas de gain de performance à l'aide de la TÊTE.

    • Supposons que le contenu est de 100 mo. Sûrement tête de moins que contenu dans la taille. Maintenant, quand nous demandons à ce que des ressources par le GET ou HEAD méthode, à votre avis, il n'y a pas de différence de performances entre eux?!
    • L'OP a déclaré 250 caractères dans le corps de la réponse. Pas 100 MO. C'est une autre question tout à fait.
    InformationsquelleAutor smassey
  7. -2

    Vous pouvez facilement faire un petit test pour mesurer la performance. Je pense que la différence de performances serait négligeable, parce que si vous êtes seulement en retournant 'Y' ou 'N' dans le corps, c'est un seul octet supplémentaire ajouté à la liste, déjà open stream.

    Je voudrais aussi aller à OBTENIR car il est plus correct. Vous n'êtes pas censé renvoyer du contenu dans les en-têtes HTTP, seules les métadonnées.

    • OBTENEZ - ce n'est pas seulement mystérieux "seul octet supplémentaire". Juste corps en entier! Dans le cas de gros documents, il pourrait être plusieurs méga-octets.
    InformationsquelleAutor AshleysBrain