Il existe actuellement 9 méthodes HTTP différentes, dont 7 pour un usage "classique" et 5 généralement utilisées dans un projet web (GET, POST, PUT, PATCH, DELETE).

Si vous n'êtes pas déjà familier avec les méthodes HTTP existante, je vous conseille de lire mon précédent article au préalable.

Et bien une nouvelle méthode HTTP est en cours de discussion afin de venir combler un trou bien connu dans la sémantique du protocole web.

La proposition est actuellement consignée dans une RFC "brouillon", disponible juste ici !

La problématique

En introduction, je parlai d'un morceau manquant dans la sémantique HTTP, mais lequel est-ce ?

Si vous avez déjà construit une API REST un tant soit peu complexe, vous aurez sûrement déjà rencontré le problème suivant:

Imaginons que je veuille créer une fonctionnalité de recherche avancée pour une ressource, avec une recherche textuelle, plus des filtres et sous-filtres assez complexes. J'ai trois problématiques :

1. Faire passer ma recherche, mes filtres et ma pagination dans les paramètres de l'url d'une requête GET est compliqué, surtout si mon schéma de filtres est un JSON complexe.
2. Si j'utilise une requête POST pour passer mes données dans le corps de la requête, je casse le principe de non-idempotence induit par POST
3. Les requêtes POST ne sont pas censées être mises en cache, hors j'ai besoin du cache pour optimiser ma fonctionnalité.

C'est pour résoudre ce genre de problèmes-ci que la méthode "QUERY" a été travaillée.

La méthode Query

Voici les caractéristiques (simplifiées) de cette méthode :

• Elle est idempotente, à l'instar de la méthode GET, car l'objectif est également de récupérer de la donnée
• Elle peut contenir un payload dans le corps de la requête
• La réponse peut-être mise en cache

Ces trois caractéristiques reflètent l'identité de cette méthode, la croisée des mondes entre les méthodes GET et POST pour ouvrir le champ sémantique du protocole.

Certaines technologies, comme le GraphQL, basées sur les deux méthodes précédemment citée pourraient, dans le futur, faire usage de cette nouvelle méthode pour éviter de tordre la sémantique du protocole par exemple.

Pour plus d'infos, voici la RFC qui documente cette future méthode : https://www.ietf.org/id/draft-ietf-httpbis-safe-method-w-body-02.html

J'espère que cet article vous aura été utile, et à bientôt sur le blog !

À propos de l'auteur

Hello, je suis Nicolas Brondin-Bernard, ingénieur web indépendant depuis 2015 passionné par le partage d'expériences et de connaissances.

Aujourd'hui je suis aussi formateur pour développeurs web juniors, tu peux me contacter sur nicolas@brondin.com, sur mon site ou devenir membre de ma newsletter pour ne jamais louper le meilleur article de la semaine et recevoir des offres exclusives !

Photo par Documerica sur Unsplash