La nouvelle méthode HTTP SEARCH
(httptoolkit.tech)-
Présentation de la méthode SEARCH, ajoutée comme nouveau draft à l’IETF
-
Pour récupérer des données complexes, il est peu efficace de se limiter aux méthodes GET/POST existantes
SEARCH /customers HTTP/1.1
Host: example.com
Content-Type: application/sql
SELECT username, email
WHERE DATEDIFF(DAY, GETDATE(), signup_date) > 7
-
En pratique, cela ne signifie pas que les requêtes SQL seront utilisées comme standard, mais que ce type de contenu de recherche peut être placé dans le corps de la requête
-
Cela permet d’utiliser GET, POST et SEARCH sur une même URL
-
L’en-tête Accept-Search permet de spécifier les formats utilisés pour la recherche :
→ Accept-Search: application/sql, application/graphql
- Basé sur le standard de la méthode SEARCH qui existait dans WebDAV (RFC 5323)
9 commentaires
OData est une convention qui permet de faire des requêtes presque de cette manière. Mais pouvoir utiliser
application/sqletapplication/graphqlsur le même endpoint... j’ai du mal à l’imaginer.J’imagine que l’usage serait plutôt dans les cas où interroger directement SQL pose problème et où, comme avec Elasticsearch, il s’agit sémantiquement d’un
GET, mais où l’on voudrait effectuer une requête en incluant un body HTTP.Au début de l’article, il est écrit « it was recently adopted as an IETF draft standard ». Ici, « recently » fait bien référence à 2015 ? Le brouillon que j’ai trouvé est celui-ci : https://tools.ietf.org/html/draft-snell-search-method-00 ; je me demandais s’il existait des modifications plus récentes.
Il s’agit de https://datatracker.ietf.org/doc/….
Il a été mis en ligne récemment, le 2021-03-31.
Pour envoyer des informations dans le body, il faudrait utiliser PUT ou POST.
Comme eux ne peuvent pas utiliser le cache,
on pourrait aussi utiliser quelque chose comme SEARCH.
Après tout, il suffit de ne l’envoyer que lorsqu’il est accepté.
Dans la volonté d’améliorer les inconvénients de get et post, cela me fait penser à GraphQL.
À partir du moment où on commence à faire passer les requêtes dans le corps de la requête, on a l’impression qu’un jour ou l’autre (si le site a été fait sans trop réfléchir), on finira par avoir des problèmes du type injection SQL…
On peut sans doute le comprendre comme une sorte de GET avec un body. De toute façon, il faudra bien valider le body…
Eh oui…