GET

Utilisation

Une requête GET récupère des données sans modifier l’état du serveur. Le contenu éventuel du corps de la requête n’a pas de sémantique généralement définie : la requête s’exprime entièrement au travers de l’URI cible et des en-têtes. Les réponses sont cacheables par défaut, ce qui fait de GET le fondement de la mise en cache sur le Web.

GET est la méthode par défaut du navigateur pour la navigation, les clics sur les liens et les soumissions de formulaire dépourvues d’attribut method.

La spécification HTTP n’interdit pas qu’une requête GET comporte un corps, mais la sémantique d’un tel corps n’est pas définie. Les navigateurs et l’API Fetch suppriment le corps des requêtes GET. De nombreux serveurs et proxys les ignorent ou les rejettent. S’appuyer sur un corps dans une requête GET n’est pas sûr du point de vue de l’interopérabilité.

Propriétés

Parce que GET est sûre et idempotente, envoyer plusieurs fois la même requête produit le même résultat et n’altère pas la ressource. Les navigateurs, les robots d’exploration et les proxys s’appuient tous sur cette garantie.

GET conditionnelle

Une requête GET devient conditionnelle lorsqu’un ou plusieurs en-têtes de validation sont présents : If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since ou If-Range. Le serveur évalue la condition et ne renvoie la représentation complète que lorsque la condition est remplie.

GET partielle

L’ajout d’un en-tête Range transforme une requête GET en requête partielle. Le serveur ne renvoie que la plage d’octets demandée, avec un statut 206. Un statut 416 indique que la plage ne peut pas être satisfaite. Les serveurs qui ne prennent pas en charge les requêtes de plage renvoient 200 avec le corps complet.

La GET partielle est utile pour reprendre des téléchargements interrompus et pour diffuser de gros fichiers par segments.

GET de base

Une requête GET minimale récupère la ressource racine. Le serveur renvoie 200 avec la représentation complète.

Requête

GET / HTTP/1.1
Host: example.com

Réponse

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<!doctype html>
<html>...

GET conditionnelle

Cette requête inclut If-Modified-Since : le serveur ne renvoie donc le corps que si la ressource a changé depuis la date indiquée. Une ressource inchangée produit un 304 sans corps.

Requête

GET / HTTP/1.1
Host: example.com
If-Modified-Since: Sat, 01 Jan 2022 12:00:00 GMT

Réponse (non modifiée)

HTTP/1.1 304 Not Modified
ETag: "abc123"

GET partielle

L’en-tête Range ne demande que les 512 premiers octets. Le serveur répond par un 206 accompagné d’un en-tête Content-Range indiquant le segment renvoyé.

Requête

GET /file.bin HTTP/1.1
Host: example.com
Range: bytes=0-511

Réponse

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-511/8192
Content-Length: 512

CORS

GET fait partie des méthodes de la liste sûre CORS. Les requêtes GET cross-origin ne déclenchent pas de requête de pré-vérification, ce qui fait de GET la méthode par défaut pour récupérer des ressources cross-origin dans les navigateurs.

GET et POST

GET récupère des données. POST soumet des données en vue d’un traitement. Les paramètres de GET transitent dans la chaîne de requête de l’URL, tandis que les paramètres de POST se trouvent dans le corps de la requête.

Les réponses à GET sont cacheables et peuvent être mises en favoris. Les réponses à POST ne sont cacheables qu’avec des informations de fraîcheur explicites. Les URL ont des limites de longueur pratiques, ce qui restreint la quantité de données que GET transporte. POST n’a pas de limite pratique de taille de corps.

GET est à la fois sûre et idempotente. POST n’est ni l’une ni l’autre. Une GET répétée renvoie le même résultat. Une POST répétée crée des ressources en double ou déclenche deux fois le traitement.

L’écart de performance entre GET et POST est négligeable. Le choix dépend de l’opération : la récupération utilise GET, la soumission utilise POST.

Sécurité

Les paramètres de GET sont visibles dans l’URL, l’historique du navigateur, les journaux du serveur et les en-têtes Referer. Les données sensibles telles que les mots de passe, les jetons et les informations personnelles identifiables ne doivent jamais figurer dans une chaîne de requête.

Les requêtes GET sont davantage exposées aux attaques CSRF par le biais des balises et qui déclenchent automatiquement des requêtes GET. POST est également vulnérable au CSRF en l’absence de jetons appropriés.

Ni GET ni POST ne fournit de chiffrement à elle seule. HTTPS est indispensable pour protéger les données en transit.

Impact SEO

Les moteurs de recherche explorent le Web avec GET. Googlebot et les autres robots récupèrent et indexent les pages via GET : une ressource n’est donc découvrable que si elle répond à une simple requête GET. Les réponses GET cacheables et idempotentes s’explorent le plus efficacement, car les robots réutilisent des validateurs comme ETag et Last-Modified pour éviter de récupérer à nouveau les pages inchangées.