java - v10 - jcms 10 sp1




Obtenir la charge utile de la requête HTTP (3)

Avoir la réponse GET varier en fonction du corps de la requête va casser la mise en cache. N'y allez pas.

Je conçois une API et je me demande si c'est bien d'envoyer une charge utile JSON sur une requête GET?

Dans cette autre question Payloads of HTTP Request Methods , nous pouvons trouver en fonction de ce lien :

  • HEAD - Pas de sémantique corporelle définie.
  • GET - Pas de sémantique du corps définie.
  • PUT - Corps supporté.
  • POST - Corps supporté.
  • DELETE - Pas de sémantique du corps définie.
  • TRACE - Corps non supporté.
  • OPTIONS - Corps supporté mais pas de sémantique (peut-être dans le futur).

Cela signifie-t-il que je ne devrais pas envoyer une requête GET avec une charge utile? Y a-t-il des risques à le faire?

  • Comme avoir certaines bibliothèques client HTTP incapables d'envoyer une telle charge utile?
  • Ou mon code API Java n'est pas portable sur certains serveurs d'applications?
  • Rien d'autre?

J'ai découvert qu'ElasticSearch utilisait une telle charge sur une requête GET:

$ curl -XGET 'http://localhost:9200/twitter/tweet/_search?routing=kimchy' -d '{
    "query": {
        "filtered" : {
            "query" : {
                "query_string" : {
                    "query" : "some query string here"
                }
            },
            "filter" : {
                "term" : { "user" : "kimchy" }
            }
        }
    }
}
'

Donc, si cette librairie populaire le fait et que personne ne se plaint, alors peut-être que je peux faire la même chose?

Par ailleurs, je voudrais savoir si cela est bon pour mélanger les paramètres queryString et la charge utile JSON? Exactement comme cette requête ElasticSearch. Si oui, existe-t-il des règles pour que nous sachions quels arguments doivent être des paramètres queryString, ou des paramètres de charge utile?

Ici nous pouvons lire: HTTP GET avec le corps de la demande

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

Oui. En d'autres termes, n'importe quel message de requête HTTP est autorisé à contenir un corps de message, et doit donc analyser les messages dans cet esprit. Cependant, la sémantique du serveur pour GET est restreinte de sorte qu'un corps, le cas échéant, n'a pas de signification sémantique pour la requête. Les exigences d'analyse sont distinctes des exigences sur la sémantique des méthodes.

Donc, oui, vous pouvez envoyer un corps avec GET, et non, il 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

Ensuite, je ne comprends pas vraiment pourquoi cela n'est jamais utile, car il est logique à mon avis d'envoyer des requêtes complexes au serveur qui ne cadrent pas bien avec queryParam ou matrixParam. Je pense que les concepteurs d'API ElasticSearch pensent la même chose ...

Je prévois de concevoir une API qui peut être appelée comme ça:

curl -XGET 'http://localhost:9000/documents/inbox?pageIndex=0&pageSize=10&sort=title'

curl -XGET 'http://localhost:9000/documents/trash?pageIndex=0&pageSize=10&sort=title'

curl -XGET 'http://localhost:9000/documents/search?pageIndex=0&pageSize=10&sort=title' -d '{
    "someSearchFilter1":"filterValue1",
    "someSearchFilter2":"filterValue2",
    "someSearchFilterList": ["filterValue3","xxx"]
    ... a lot more ...
}
'

Cela vous semble-t-il bien? Basé sur les considérations ci-dessus.



Voir aussi: HTTP GET avec le corps de la requête - pour plus de détails à ce sujet.

L'essentiel est: Oui vous pouvez, mais vous ne devriez probablement pas pour diverses raisons, y compris:

  • Vous ignorez probablement les recommandations de spécification HTTP (vous voulez probablement POST)
  • Vous pouvez introduire des problèmes de mise en cache
  • Ce n'est pas intuitif dans la mesure où les API REST vont




elasticsearch