http rfc9110 rest web-architecture standards

La sémantique HTTP expliquée : Maîtrisez la RFC 9110 pour le Web moderne

Comprenez le cœur du Web. Un guide sur la RFC 9110, couvrant les méthodes HTTP, les codes d'état et la sémantique des en-têtes.

2026-04-11

La sémantique HTTP expliquée : Maîtrisez la RFC 9110 pour le Web moderne

En 2022, l'IETF a publié la RFC 9110, un document monumental qui a rendu obsolètes plusieurs anciennes RFC (comme la RFC 7231) pour devenir l'autorité définitive sur la sémantique HTTP. Alors que HTTP/2 et HTTP/3 ont changé la façon dont les données sont transportées, la sémantique — la signification des méthodes, des codes d'état et des en-têtes — reste le fondement du Web.

Qu'est-ce que la RFC 9110 (sémantique HTTP) ?

La RFC 9110 définit l'architecture commune du protocole de transfert hypertexte (HTTP). Elle est indépendante de la version du protocole (HTTP/1.1, HTTP/2 ou HTTP/3). Si vous voulez savoir ce qu'un 403 Forbidden signifie réellement ou comment une requête POST doit se comporter par rapport à un PUT, la RFC 9110 est la source de vérité.

Elle fournit un vocabulaire cohérent pour :

  • Les Ressources et les identifiants de ressources uniformes (URI).
  • Les Messages (requêtes et réponses).
  • Les Méthodes (GET, POST, etc.).
  • Les Codes d'état (200, 404, etc.).
  • Les Champs d'en-tête.

Principes fondamentaux de la sémantique HTTP

1. Méthodes de requête et idempotence

L'un des concepts les plus importants de la RFC 9110 est la distinction entre les méthodes sûres (Safe) et idempotentes (Idempotent).

Méthode Sûre Idempotente Description
GET Oui Oui Récupère des données sans effets secondaires.
HEAD Oui Oui Identique à GET mais ne renvoie pas de corps.
PUT Non Oui Remplace une ressource ; la répéter n'a pas d'effet supplémentaire.
DELETE Non Oui Supprime une ressource.
POST Non Non Traite des données ; plusieurs requêtes peuvent créer plusieurs ressources.

2. Classes de codes d'état

La RFC 9110 organise les codes d'état en cinq classes :

  • 1xx (Information) : Requête reçue, poursuite du processus.
  • 2xx (Succès) : L'action a été reçue, comprise et acceptée avec succès.
  • 3xx (Redirection) : D'autres actions doivent être entreprises pour compléter la requête.
  • 4xx (Erreur client) : La requête contient une mauvaise syntaxe ou ne peut être satisfaite.
  • 5xx (Erreur serveur) : Le serveur n'a pas pu satisfaire une requête apparemment valide.

Scénarios d'application pratique

Conception d'API RESTful

Le respect de la RFC 9110 garantit que votre API est cohérente et se comporte comme prévu par les clients HTTP standards et les caches. Par exemple, utiliser 201 Created après un POST réussi au lieu d'un générique 200 OK.

Optimisation du cache

La RFC 9110 définit le fonctionnement des en-têtes Vary, ETag et Last-Modified. Une mise en œuvre correcte permet aux CDN et aux navigateurs de mettre en cache les données efficacement, réduisant ainsi la charge du serveur.

Négociation de contenu

Le protocole permet à un client de demander un format spécifique (ex : Accept: application/json) et au serveur de répondre avec la meilleure représentation disponible.


Comparaison : RFC 7231 vs RFC 9110

La RFC 9110 n'a pas fondamentalement changé le fonctionnement de HTTP, mais elle a considérablement amélioré la documentation :

  • Consolidation : Elle a fusionné les sémantiques de plusieurs documents en un seul.
  • Clarté : Elle a clarifié des points ambigus concernant le contenu partiel (requêtes Range) et l'authentification.
  • Versionnage : Elle sépare explicitement le "quoi" (sémantique) du "comment" (HTTP/1.1 vs HTTP/3).

FAQ

Q : La RFC 9110 ne concerne-t-elle que le HTTP/1.1 ?
R : Non. La RFC 9110 définit la sémantique qui s'applique à toutes les versions de HTTP, y compris HTTP/2 et HTTP/3.

Q : Quelle est la différence entre POST et PUT ?
R : Selon la RFC 9110, PUT est idempotent (remplace la ressource à une URI spécifique), tandis que POST ne l'est pas (il soumet des données pour être traitées).

Q : Quand dois-je utiliser un 403 plutôt qu'un 401 ?
R : Utilisez 401 Unauthorized lorsqu'une authentification est requise et a échoué ou n'a pas été fournie. Utilisez 403 Forbidden lorsque le serveur comprend la requête mais refuse de l'autoriser (même avec des identifiants valides).


Outils associés

  • Formateur JSON - Parfait pour inspecter les réponses JSON de vos API HTTP.
  • Encodeur/Décodeur URL - Essentiel pour préparer des URI valides selon les standards HTTP.
  • Décodeur JWT - Décodez les jetons souvent transportés dans l'en-tête Authorization.