HTTP GET avec le corps de la requête

Question

Je suis le développement d'un nouveau service web RESTful pour notre application.

Quand faire un GET sur certaines entités, les clients peuvent demander le contenu de l'entité. Si ils veulent ajouter d'autres paramètres (par exemple le tri d'une liste), ils peuvent ajouter ces paramètres dans la chaîne de requête.

Sinon, je veux que les gens à être en mesure de spécifier ces paramètres dans le corps de la requête. HTTP/1.1 ne semble pas interdire explicitement cela. Cela leur permettra de spécifier plus d'informations, pourrait rendre plus facile pour spécifier complexe des requêtes xml.

Mes questions:

• Est-ce une bonne idée?
• Sera HTTP, les clients ont des problèmes avec l'utilisation de corps de requête dans une requête GET?

http://tools.ietf.org/html/rfc2616

Answer 1

Roy Fielding commentaire sur l'inclusion d'un corps avec une requête GET.

Oui. En d'autres termes, toute requête HTTP message est autorisé à contenir le corps d'un message, et doit donc analyser les messages avec cela à l'esprit. Serveur de la sémantique pour l'OBTENIR, cependant, sont restreints tels qu'un corps, le cas échéant, n'a pas de sens sémantique de la demande. Les exigences sur l'analyse sont séparés les prescriptions relatives à la méthode de la sémantique.

Donc, oui, vous pouvez envoyer un corps avec elle, et non, il n'est jamais utile de le faire.

C'est la partie de la couche de conception de HTTP/1.1 qui deviendra clair encore une fois que la spécification est partitionné (travaux en cours).

....Roy

Oui, vous pouvez envoyer un corps de requête à OBTENIR, mais il ne devrait pas avoir de sens. Si vous lui donner un sens par l'analyse sur le serveur et changer votre réponse en vous basant sur son contenu vous êtes violation du protocole HTTP/1.1 spec.

Answer 2

Alors que vous pouvez le faire, dans la mesure où il n'est pas explicitement interdit par la spécification HTTP, je suggère de les éviter tout simplement parce que les gens ne vous attendez pas à des choses à travailler de cette façon. Il y a plusieurs étapes dans une requête HTTP de la chaîne, et bien qu'ils "la plupart" sont conformes à la spécification HTTP, la seule chose que vous êtes assuré, c'est qu'ils se comportent comme traditionnellement utilisé par les navigateurs web. (Je pense à des choses comme transparent proxies, des accélérateurs, A/V à outils, etc.)

C'est l'esprit derrière la Robustesse Principe à peu près "être libéral dans ce que vous acceptez, et prudent dans ce que vous envoyer", vous ne voulez pas de repousser les limites d'un cahier des charges sans une bonne raison.

Toutefois, si vous avez une bonne raison d'aller pour elle.

Answer 3

Vous serez susceptibles de rencontrer des problèmes si jamais vous essayez de prendre avantage de la mise en cache. Les procurations ne sont pas aller chercher dans le corps pour voir si les paramètres ont un impact sur la réponse.

Answer 4

Ni restclient ni le RESTE de la console de soutenir cela, mais curl n'.

La spécification HTTP, dit dans la section 4.3

Un message du corps ne DOIT PAS être inclus dans la demande que si la spécification de la méthode de la requête (article 5.1.1) ne permet pas l'envoi d'une entité-corps dans les demandes.

La Section 5.1.1 nous ramène à l'article 9.x pour les différentes méthodes. Aucun d'entre eux interdisent explicitement l'inclusion d'un corps de message. Cependant...

La Section 5.2 dit

Le exacte de la ressource identifiée par une demande Internet est déterminé par l'examen de la Demande-URI et le champ d'en-tête d'Hôte.

et l'Article 9.3 dit

La méthode GET récupérer des informations (sous la forme d'une entité) est identifié par l'URI de Demande.

Qui, ensemble, suggèrent que lors du traitement d'une requête GET, un serveur n'est pas nécessaire d'examiner autre chose que l'URI de la Requête et de l'Hôte champ d'en-tête.

En résumé, la spécification HTTP ne vous empêche pas de l'envoi d'un message-corps avec de l'OBTENIR, mais il est suffisamment ambigus pour que cela ne m'étonne pas si il n'a pas été pris en charge par tous les serveurs.

Answer 5

Le serveur qui l'ignore? – fijiaaron Août 30 '12 à 21:27

Google par exemple, est en train de faire pire que de l'ignorer, il va la considérer comme une erreur!

Essayez-le vous-même avec une simple netcat:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(1234 contenu est suivie par CR-LF, c'est donc un total de 6 octets)

et vous obtiendrez:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That's an error.
Your client has issued a malformed or illegal request. That's all we know.

Vous ne bénéficiez également de 400 Bad Request à partir de Bing, Apple, etc... qui sont servis par AkamaiGhost.

Donc je ne le conseille pas à l'aide de requêtes GET avec un corps d'entité.