La nouvelle méthode HTTP QUERY

Explication de la nouvelle méthode HTTP QUERY définie par la RFC 10008

Dans les API RESTful existantes, GET comme POST montraient leurs limites pour gérer des recherches complexes. Après de longues discussions, la méthode QUERY a été standardisée pour résoudre ce problème.

Limites de GET

• Lorsque des filtres complexes ou des requêtes relationnelles sont envoyés via des paramètres d’URL, l’URL peut devenir excessivement longue et se heurter aux limites de longueur du navigateur ou du serveur
• Les caractères non ASCII ou spéciaux nécessitent un encodage, ce qui augmente la taille de la requête
• La manière de représenter des tableaux ou des structures imbriquées n’est pas standardisée (roles[]=admin vs roles=admin)
• Comme le serveur ou le middleware enregistre les paramètres d’URL dans les logs, cela pose problème pour le transfert de données sensibles
• Envoyer un corps de requête avec GET n’est pas explicitement interdit par la spécification, mais comme le traitement varie selon les proxys, pare-feu et navigateurs, c’est en pratique inutilisable

Problèmes du contournement via POST

• Il permet d’envoyer un corps de requête, mais POST est défini comme non idempotent, donc les nouvelles tentatives automatiques après échec ne sont pas sûres
• Les proxys et middlewares ne peuvent pas reconnaître qu’il s’agit d’une opération en lecture seule, ce qui empêche des optimisations comme la mise en cache automatique
• Employer POST, sémantiquement destiné à la création ou au traitement de ressources, pour des recherches ne correspond pas aux principes de conception RESTful

Méthode QUERY

• Une nouvelle méthode HTTP qui, comme GET, est sûre (safe) et idempotente (idempotent), tout en pouvant inclure un corps de requête
• Elle peut être mise en cache, mais comme le corps de requête doit être inclus dans la clé de cache lors de l’implémentation, la mise en cache est plus complexe qu’avec GET
• En résumé, son objectif principal est de « remplacer POST pour les requêtes en lecture seule »

Points d’attention

• La prise en charge de QUERY par les clients, proxys et serveurs reste encore limitée, et un support complet pourra prendre du temps
• S’il suffit d’utiliser de simples paramètres de requête GET, il n’est pas nécessaire de changer
• Si l’on a besoin de partager ou de mettre en favori l’URL de données filtrées, GET reste plus adapté

[jongyeol]

Envoyer un corps de requête avec GET n’est pas explicitement interdit par la spécification, mais comme la manière de le traiter diffère selon les proxys, les pare-feu et les navigateurs, c’est en pratique inutilisable.

Euh… ils n’ont pas pensé au fait que, selon les proxys, pare-feu et navigateurs, la méthode QUERY pourrait ne pas être prise en charge avant encore une dizaine d’années ? Ou bien est-ce qu’ils ont simplement visé le très long terme ?

[tesha001]

Je pense que c’est la seconde option.

[click]

Je me souviens qu’un service d’API d’une certaine entreprise recevait bien les requêtes POST, mais ne fonctionnait pas si on ne lui passait pas exactement les mêmes paramètres dans l’URL.
En Corée, il y a encore pas mal de cas où les gens se demandent déjà ce que sont PUT ou DELETE ; alors je me demande bien combien de temps il faudra pour que QUERY s’impose aussi.

[sea715]

??? : arrêtez de faire du REST et unifiez tout simplement sur POST

[savvykang]

???: POST est bon pour la sécurité

[ultimategamer]

Le document RFC est ici : https://datatracker.ietf.org/doc/rfc10008/.
GET a aussi l’inconvénient d’allonger l’URL, mais il me semble qu’il a également l’avantage de permettre de partager directement l’adresse URL telle quelle, par exemple lorsqu’on veut partager le résultat d’un filtre de recherche spécifique dans ElasticSearch.

Comme il existe probablement déjà de nombreux usages implicites où les requêtes GET partent du principe qu’elles sont saisies dans la barre d’adresse du navigateur, il faudra sans doute beaucoup de temps, au-delà du seul support technique, pour que cela s’installe.