HTTP GET avec corps de demande

Je développe un nouveau webservice RESTful pour notre application.

Lors d'une opération GET sur certaines entités, les clients peuvent demander le contenu de l'entité. S'ils souhaitent ajouter des paramètres (par exemple, trier une liste), ils peuvent ajouter ces paramètres dans la chaîne de requête.

Sinon, je veux que les gens puissent spécifier ces paramètres dans le corps de la demande. HTTP / 1.1 ne semble pas l'interdire explicitement. Cela leur permettra de spécifier plus d'informations, ce qui pourrait faciliter la spécification de requêtes XML complexes.

Mes questions:

• Est-ce une bonne idée tout à fait?
• Les clients HTTP auront-ils des problèmes avec l'utilisation des corps de demande dans une demande GET?

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

Commentaire de Roy Fielding sur l'inclusion d'un corps avec une demande GET .

Oui. En d'autres termes, tout message de requête HTTP peut contenir un corps de message et doit donc analyser les messages en gardant cela à l'esprit. Cependant, la sémantique du serveur pour GET est limitée de telle sorte qu'un corps, le cas échéant, n'a aucune signification sémantique pour la demande. Les exigences relatives à l'analyse sont distinctes des exigences relatives à la sémantique des méthodes.

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

Cela fait partie de la conception en couches de HTTP / 1.1 qui redeviendra claire une fois la spécification partitionnée (travail en cours).

.... Roy

Oui, vous pouvez envoyer un corps de requête avec GET mais cela ne devrait avoir aucun sens. Si vous lui donnez un sens en l'analysant sur le serveur et en modifiant votre réponse en fonction de son contenu , vous ignorez cette recommandation dans la spécification HTTP / 1.1, section 4.3 :

[...] si la méthode de demande n'inclut pas de sémantique définie pour un corps d'entité, alors le corps de message DEVRAIT être ignoré lors du traitement de la demande.

Et la description de la méthode GET dans la spécification HTTP / 1.1, section 9.3 :

La méthode GET signifie récupérer toutes les informations ([...]) identifiées par l'URI de demande.

qui indique que le corps de la demande ne fait pas partie de l'identification de la ressource dans une demande GET, seulement l'URI de la demande.

Mise à jour Le RFC2616 référencé comme "spécification HTTP / 1.1" est désormais obsolète. En 2014, il a été remplacé par les RFC 7230-7237. La citation "le corps du message DEVRAIT être ignoré lors du traitement de la demande" a été supprimée. C'est maintenant juste "Le cadrage du message de demande est indépendant de la sémantique de la méthode, même si la méthode ne définit aucune utilisation pour un corps de message" La deuxième citation "La méthode GET signifie récupérer toutes les informations ... est identifiée par l'URI de la demande" A été supprimée. - D'un commentaire

Bien que vous puissiez le faire, dans la mesure où cela n'est pas explicitement exclu par la spécification HTTP, je suggère de l'éviter simplement parce que les gens ne s'attendent pas à ce que les choses fonctionnent de cette façon. Il y a de nombreuses phases dans une chaîne de requêtes HTTP et bien qu'elles soient "principalement" conformes à la spécification HTTP, la seule chose dont vous êtes assuré est qu'elles se comporteront comme traditionnellement utilisées par les navigateurs Web. (Je pense à des choses comme des proxys transparents, des accélérateurs, des kits d'outils A / V, etc.)

C'est l'esprit qui sous-tend le principe de robustesse: "soyez libéral dans ce que vous acceptez et conservateur dans ce que vous envoyez", vous ne voulez pas repousser les limites d'une spécification sans raison valable.

Cependant, si vous avez une bonne raison, allez-y.

Vous rencontrerez probablement des problèmes si vous essayez de profiter de la mise en cache. Les proxys ne vont pas regarder dans le corps GET pour voir si les paramètres ont un impact sur la réponse.

Ni restclient ni la console REST ne prennent en charge cela, mais curl le fait.

La spécification HTTP dit dans la section 4.3

Un corps de message NE DOIT PAS être inclus dans une demande si la spécification de la méthode de demande (section 5.1.1) ne permet pas d'envoyer un corps d'entité dans les demandes.

La section 5.1.1 nous redirige vers la section 9.x pour les différentes méthodes. Aucun d'entre eux n'interdit explicitement l'inclusion d'un corps de message. Toutefois...

La section 5.2 dit

La ressource exacte identifiée par une demande Internet est déterminée en examinant à la fois l'URI de la demande et le champ d'en-tête Host.

et la section 9.3 dit

La méthode GET signifie récupérer toutes les informations (sous la forme d'une entité) identifiées par l'URI de demande.

Ce qui, ensemble, suggère que lors du traitement d'une demande GET, un serveur n'est pas tenu d'examiner autre chose que le champ d'en-tête Request-URI et Host.

En résumé, la spécification HTTP ne vous empêche pas d'envoyer un corps de message avec GET mais il y a suffisamment d'ambiguïté pour que cela ne m'étonne pas s'il n'était pas pris en charge par tous les serveurs.

Elasticsearch accepte les requêtes GET avec un corps. Il semble même que ce soit la voie préférée: Elasticsearch guide

Certaines bibliothèques clientes (comme le pilote Ruby) peuvent consigner la commande cry sur stdout en mode développement et elle utilise largement cette syntaxe.

Ce que vous essayez d'atteindre a été fait depuis longtemps avec une méthode beaucoup plus courante et qui ne repose pas sur l'utilisation d'une charge utile avec GET.

Vous pouvez simplement créer votre type de recherche spécifique, ou si vous voulez être plus RESTful, utilisez quelque chose comme OpenSearch et POSTEZ la demande à l'URI que le serveur a demandé, par exemple / search. Le serveur peut ensuite générer le résultat de la recherche ou créer l'URI final et rediriger à l'aide d'un 303.

Cela a l'avantage de suivre la méthode PRG traditionnelle, aide les intermédiaires de cache à mettre en cache les résultats, etc.

Cela dit, les URI sont de toute façon encodés pour tout ce qui n'est pas ASCII, tout comme application / x-www-form-urlencoded et multipart / form-data. Je recommanderais d'utiliser cela plutôt que de créer un autre format json personnalisé si votre intention est de prendre en charge les scénarios ReSTful.

Vous pouvez envoyer un GET avec un corps ou envoyer un POST et renoncer à la religiosité RESTish (ce n'est pas si mal, il y a 5 ans, il n'y avait qu'un seul membre de cette foi - ses commentaires liés ci-dessus).

Les décisions ne sont pas non plus importantes, mais l'envoi d'un corps GET peut éviter des problèmes pour certains clients - et certains serveurs.

Faire un POST peut avoir des obstacles avec certains frameworks RESTish.

Julian Reschke a suggéré ci-dessus d'utiliser un en-tête HTTP non standard comme "SEARCH" qui pourrait être une solution élégante, sauf qu'il est encore moins susceptible d'être pris en charge.

Il pourrait être plus productif d'énumérer les clients qui peuvent et ne peuvent pas faire chacun des éléments ci-dessus.

Clients qui ne peuvent pas envoyer de GET avec corps (à ma connaissance):

• XmlHTTPRequest Fiddler

Clients pouvant envoyer un GET avec body:

• la plupart des navigateurs

Serveurs et bibliothèques pouvant récupérer un corps depuis GET:

• Apache
• PHP

Serveurs (et mandataires) qui suppriment un corps de GET:

• ?

Quel serveur l'ignorera? - fijiaaron 30 août 12 à 21:27

Google, par exemple, fait pire que de l'ignorer, il considérera que c'est une erreur !

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

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

1234

(le contenu 1234 est suivi de CR-LF, ce qui fait 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 obtenez également 400 Bad Request de Bing, Apple, etc ... qui sont servis par AkamaiGhost.

Je ne conseillerais donc pas d'utiliser les requêtes GET avec une entité corps.

J'ai posé cette question au groupe de travail HTTP IETF. Le commentaire de Roy Fielding (auteur du document http / 1.1 en 1998) était que

"... une implémentation serait interrompue pour faire autre chose que d'analyser et de jeter ce corps s'il était reçu"

La RFC 7213 (HTTPbis) indique:

"Une charge utile dans un message de demande GET n'a pas de sémantique définie;"

Il semble clair maintenant que l'intention était d'interdire la signification sémantique sur les corps de demande GET, ce qui signifie que le corps de demande ne peut pas être utilisé pour affecter le résultat.

Il existe des procurations qui briseront définitivement votre demande de différentes manières si vous incluez un corps sur GET.

Donc en résumé, ne le faites pas.

De RFC 2616, section 4.3 , «Corps du message»:

Un serveur DEVRAIT lire et transmettre un corps de message sur toute demande; si la méthode de demande n'inclut pas de sémantique définie pour un corps d'entité, alors le corps du message DEVRAIT être ignoré lors du traitement de la demande.

Autrement dit, les serveurs doivent toujours lire tout corps de demande fourni à partir du réseau (vérifiez Content-Length ou lisez un corps fragmenté, etc.). En outre, les mandataires doivent transmettre tout corps de demande qu'ils reçoivent. Ensuite, si la RFC définit la sémantique du corps pour la méthode donnée, le serveur peut réellement utiliser le corps de la requête pour générer une réponse. Cependant, si le RFC ne définit pas de sémantique pour le corps, le serveur doit l'ignorer.

Ceci est conforme à la citation de Fielding ci-dessus.

La section 9.3 , «GET», décrit la sémantique de la méthode GET et ne mentionne pas les corps de requête. Par conséquent, un serveur doit ignorer tout corps de demande qu'il reçoit sur une demande GET.

Selon XMLHttpRequest, ce n'est pas valide. De la norme :

4.5.6 La send()méthode

client . send([body = null])

Lance la demande. L'argument facultatif fournit le corps de la demande. L'argument est ignoré si la méthode de demande est GETou HEAD.

Lève une InvalidStateErrorexception si l'un des états n'est pas ouvert ou si l' send()indicateur est défini.

La méthode doit exécuter ces étapes:send(body)

1. Si l'état n'est pas ouvert , lève une InvalidStateErrorexception.
2. Si l' send()indicateur est défini, lancez une InvalidStateErrorexception.
3. Si la méthode de demande est GETor HEAD, définissez body sur null.
4. Si le corps est nul, passez à l'étape suivante.

Cependant, je ne pense pas que ce soit le cas, car la demande GET peut nécessiter un contenu volumineux.

Donc, si vous comptez sur XMLHttpRequest d'un navigateur, il est probable que cela ne fonctionnera pas.

Si vous voulez vraiment envoyer un corps JSON / XML cachable à une application Web, le seul endroit raisonnable pour mettre vos données est la chaîne de requête encodée avec RFC4648: Encodage Base 64 avec URL et nom de fichier Safe Alphabet . Bien sûr, vous pouvez simplement encoder JSON en url et mettre dans la valeur du paramètre URL, mais Base64 donne un résultat plus petit. Gardez à l'esprit qu'il existe des restrictions de taille d'URL, voir Quelle est la longueur maximale d'une URL dans différents navigateurs?.

Vous pouvez penser que le =caractère de remplissage de Base64 peut être mauvais pour la valeur de paramètre d'URL, mais il ne semble pas - voir cette discussion: http://mail.python.org/pipermail/python-bugs-list/2007-F February / 037195.html . Cependant, vous ne devez pas mettre de données codées sans nom de paramètre, car une chaîne codée avec un remplissage sera interprétée comme une clé de paramètre avec une valeur vide. J'utiliserais quelque chose comme ?_b64=<encodeddata>.

Je ne conseillerais pas cela, cela va à l'encontre des pratiques standard et n'offre pas grand-chose en retour. Vous voulez garder le corps du contenu, pas des options.

Qu'en est-il des en-têtes encodés en base64 non conformes? "SOMETHINGAPP-PARAMS: sdfSD45fdg45 / aS"

Restrictions de longueur hm. Ne pouvez-vous pas faire la distinction entre vos significations POST? Si vous voulez des paramètres simples comme le tri, je ne vois pas pourquoi ce serait un problème. Je suppose que c'est la certitude qui vous inquiète.

Je suis contrarié par le fait que REST car le protocole ne prend pas en charge la POO et Get méthode en est la preuve. Comme solution, vous pouvez sérialiser votre DTO en JSON puis créer une chaîne de requête. Côté serveur, vous pourrez désérialiser la chaîne de requête vers le DTO.

Jetez un oeil sur:

• Conception basée sur les messages dans ServiceStack
• Création de services Web basés sur des messages RESTful avec WCF

L'approche basée sur les messages peut vous aider à résoudre la restriction de la méthode Get. Vous pourrez envoyer n'importe quel DTO comme avec le corps de la demande

La structure de service Web Nelibur fournit des fonctionnalités que vous pouvez utiliser

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

Par exemple, il fonctionne avec Curl, Apache et PHP.

Fichier PHP:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

Commande de la console:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

Production:

GET
{"the": "body"}

À mon humble avis, vous pouvez simplement envoyer le JSONcodé (c'est-à-dire encodeURIComponent) dans le URL, de cette façon, vous ne violez pas les HTTPspécifications et obtenez votre JSONau serveur.

Vous avez une liste d'options bien meilleures que l'utilisation d'un corps de requête avec GET.

Supposons que vous ayez des catégories et des éléments pour chaque catégorie. Les deux doivent être identifiés par un identifiant ("catid" / "itemid" pour cet exemple). Vous souhaitez trier selon un autre paramètre "sortby" dans un "ordre" spécifique. Vous voulez passer des paramètres pour "sortby" et "order":

Vous pouvez:

1. Utilisez des chaînes de requête, par exemple example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. Utilisez mod_rewrite (ou similaire) pour les chemins: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. Utilisez les en-têtes HTTP individuels que vous transmettez avec la demande
4. Utilisez une méthode différente, par exemple POST, pour récupérer une ressource.

Tous ont leurs inconvénients, mais sont bien meilleurs que d'utiliser un GET avec un corps.

Même si un outil populaire utilise cela, comme souvent cité sur cette page, je pense que c'est quand même une assez mauvaise idée, étant trop exotique, malgré ce qui n'est pas interdit par la spécification.

De nombreuses infrastructures intermédiaires peuvent simplement rejeter de telles demandes.

Par exemple, oubliez d'utiliser certains des CDN disponibles devant votre site Web, comme celui- ci :

Si une GETdemande de visualiseur inclut un corps, CloudFront renvoie un code de statut HTTP 403 (interdit) au visualiseur.

Et oui, vos bibliothèques clientes peuvent également ne pas prendre en charge l'émission de telles demandes, comme indiqué dans ce commentaire .

J'utilise RestTemplate du framework Spring dans mon programme client et, côté serveur, j'ai défini une requête GET avec un corps Json. Mon objectif principal est le même que le vôtre: lorsque la demande a de nombreux paramètres, les mettre dans le corps semble plus ordonné que de les mettre dans la chaîne d'URI prolongée. Oui?

Mais, malheureusement, cela ne fonctionne pas! Le côté serveur a levé l'exception suivante:

org.springframework.http.converter.HttpMessageNotReadableException: le corps de demande requis est manquant ...

Mais je suis sûr que le corps du message est correctement fourni par mon code client, alors qu'est-ce qui ne va pas?

J'ai tracé la méthode RestTemplate.exchange () et trouvé ce qui suit:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

Veuillez noter que dans la méthode executeInternal (), l'argument d'entrée 'bufferedOutput' contient le corps du message fourni par mon code. Je l'ai vu à travers le débogueur.

Cependant, en raison de prepareConnection (), le getDoOutput () dans executeInternal () renvoie toujours false ce qui, à son tour, rend le bufferedOutput complètement ignoré! Il n'est pas copié dans le flux de sortie.

Par conséquent, mon programme serveur n'a reçu aucun corps de message et a levé cette exception.

Ceci est un exemple sur le RestTemplate du framework Spring. Le fait est que, même si le corps du message n'est plus interdit par la spécification HTTP, certaines bibliothèques ou infrastructures client ou serveur peuvent toujours se conformer à l'ancienne spécification et rejeter le corps du message de la demande GET.