Codes de statut HTTP

Référence complète de tous les codes de statut HTTP avec descriptions et exemples.

61 sur 61 affichés

1xx Informatif

4 codes de statut

100

Continuer

Le serveur a recu les en-tetes de la requete et le client doit poursuivre l'envoi du corps de la requete. Cela permet d'optimiser les telechargements volumineux en laissant le client verifier si le serveur acceptera la requete avant d'envoyer la totalite des donnees.

Cas d'utilisation courants: Utilise lorsqu'un client envoie un en-tete Expect: 100-continue avant de telecharger un corps de requete volumineux, permettant au serveur de rejeter la requete en amont sans gaspiller de bande passante.

RFC 9110

101

Changement de protocole

Le serveur change de protocole comme demande par le client via un en-tete Upgrade. Le serveur accepte et communiquera en utilisant le nouveau protocole apres cette reponse.

Cas d'utilisation courants: Le plus souvent observe lors de la mise a niveau d'une connexion HTTP vers une connexion WebSocket. Le client envoie un en-tete Upgrade: websocket et le serveur repond avec 101 pour confirmer le changement.

RFC 9110

102

Traitement en cours

Le serveur a recu la requete et la traite, mais aucune reponse n'est encore disponible. Cela empeche le client d'expirer pendant que le serveur travaille sur une operation de longue duree.

Cas d'utilisation courants: Utilise dans les operations WebDAV qui peuvent prendre du temps. Informe le client que le serveur n'a pas coupe la connexion et travaille encore sur la requete.

RFC 2518

103

Indices precoces

Le serveur envoie des en-tetes de reponse preliminaires avant la reponse finale. Cela permet au client de commencer a precharger des ressources pendant que le serveur prepare encore la reponse complete.

Cas d'utilisation courants: Utilise pour envoyer des en-tetes Link en avance afin que le navigateur puisse precharger le CSS, le JavaScript ou les polices avant l'arrivee de la reponse HTML finale, ameliorant les performances de chargement de la page.

RFC 8297

2xx Succès

10 codes de statut

200

OK

La requete a reussi. La signification du succes depend de la methode HTTP : GET retourne la ressource demandee, POST retourne le resultat de l'action, et ainsi de suite.

Cas d'utilisation courants: La reponse de succes standard pour la plupart des appels API. Utilisee lorsqu'une requete GET retourne des donnees, qu'une requete PUT met a jour une ressource ou qu'une operation se termine avec succes avec un corps de reponse.

RFC 9110

Requête

GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Réponse

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "created_at": "2025-08-15T10:30:00Z"
}

201

Cree

La requete a ete satisfaite et une nouvelle ressource a ete creee. La reponse inclut generalement un en-tete Location pointant vers la ressource nouvellement creee.

Cas d'utilisation courants: Retourne apres une requete POST reussie qui cree une nouvelle ressource, comme la creation d'un nouveau compte utilisateur, l'ajout d'un article de blog ou le telechargement d'un fichier.

RFC 9110

Requête

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}

Réponse

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/42

{
  "id": 42,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "created_at": "2025-08-15T10:30:00Z"
}

202

Accepte

La requete a ete acceptee pour traitement, mais le traitement n'est pas termine. La requete pourrait ou non etre finalement executee, car elle pourrait etre refusee lors du traitement effectif.

Cas d'utilisation courants: Utilise pour les operations asynchrones ou le serveur met une tache en file d'attente pour un traitement ulterieur, comme l'envoi d'un e-mail, la generation d'un rapport ou le declenchement d'un traitement par lots.

RFC 9110

203

Information non-autorisee

La requete a reussi mais les metadonnees retournees dans les en-tetes peuvent provenir d'une copie locale ou tierce plutot que du serveur d'origine. La charge utile incluse est une version modifiee de la reponse 200 du serveur d'origine.

Cas d'utilisation courants: Rarement utilise en pratique. Peut apparaitre lorsqu'un proxy transformant modifie les en-tetes de reponse du serveur d'origine, indiquant que les metadonnees peuvent ne pas correspondre a l'original.

RFC 9110

204

Pas de contenu

Le serveur a satisfait la requete avec succes et il n'y a pas de contenu supplementaire a envoyer dans le corps de la reponse. La reponse peut inclure des en-tetes mis a jour.

Cas d'utilisation courants: Retourne apres une requete DELETE reussie, ou une mise a jour PUT/PATCH ou aucun corps de reponse n'est necessaire. Egalement utilise pour les operations de type fire-and-forget ou un simple accuse de reception suffit.

RFC 9110

Requête

DELETE /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Réponse

HTTP/1.1 204 No Content

205

Reinitialiser le contenu

Le serveur a satisfait la requete et souhaite que l'agent utilisateur reinitialise la vue du document qui a provoque l'envoi de la requete. Aucun corps de reponse n'est inclus.

Cas d'utilisation courants: Utilise pour indiquer au client de reinitialiser le formulaire ou l'interface qui a soumis la requete. Par exemple, apres la soumission reussie d'un formulaire, le serveur peut signaler au navigateur d'effacer les champs du formulaire.

RFC 9110

206

Contenu partiel

Le serveur ne livre qu'une partie de la ressource en raison d'un en-tete Range envoye par le client. Cela est utilise pour les telechargements avec reprise et le streaming multimedia.

Cas d'utilisation courants: Utilise lorsqu'un client demande une plage d'octets specifique d'un fichier volumineux, permettant des fonctionnalites comme les telechargements avec reprise, la recherche dans les videos et les telechargements paralleles par morceaux.

RFC 9110

207

Multi-statut

Une reponse WebDAV qui transmet des informations sur plusieurs ressources dans des situations ou plusieurs codes de statut pourraient etre appropries. Le corps de la reponse est un document XML contenant des codes de statut individuels pour chaque sous-requete.

Cas d'utilisation courants: Utilise dans les operations par lots WebDAV ou chaque sous-operation peut avoir un resultat different. Par exemple, la copie de plusieurs fichiers ou certains reussissent et d'autres echouent.

RFC 4918

208

Deja signale

Utilise a l'interieur d'un element de reponse DAV: propstat pour eviter d'enumerer de maniere repetee les membres internes de plusieurs liaisons vers la meme collection.

Cas d'utilisation courants: Un statut WebDAV utilise pour eviter de lister la meme ressource plusieurs fois lorsqu'elle apparait a plusieurs emplacements au sein d'une collection en raison de liaisons.

RFC 5842

226

IM utilise

Le serveur a satisfait une requete GET pour la ressource, et la reponse est une representation du resultat d'une ou plusieurs manipulations d'instance appliquees a l'instance actuelle.

Cas d'utilisation courants: Utilise avec l'encodage delta pour envoyer uniquement les changements (deltas) entre la version actuelle d'une ressource et une version precedemment mise en cache, reduisant l'utilisation de la bande passante.

RFC 3229

3xx Redirection

7 codes de statut

300

Choix multiples

La ressource cible a plus d'une representation et l'utilisateur ou l'agent utilisateur peut en selectionner une preferee. Le serveur peut inclure une liste des representations disponibles.

Cas d'utilisation courants: Rarement utilise en pratique. Pourrait etre utilise lorsqu'une ressource est disponible dans plusieurs formats (par ex. JSON, XML, HTML) et que le serveur souhaite que le client choisisse explicitement.

RFC 9110

301

Deplace de maniere permanente

La ressource cible s'est vu attribuer un nouveau URI permanent et toute reference future a cette ressource devrait utiliser l'URI Location retourne. Les moteurs de recherche mettront a jour leur index.

Cas d'utilisation courants: Utilise lorsqu'une page ou un point de terminaison API a ete definitivement deplace vers une nouvelle URL. Essentiel pour le SEO lors de la restructuration d'un site, du changement de nom de domaine ou de l'abandon d'anciens modeles d'URL.

RFC 9110

Requête

GET /old-page HTTP/1.1
Host: www.example.com

Réponse

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page
Content-Type: text/html

<html><body>This page has moved to <a href="https://www.example.com/new-page">/new-page</a>.</body></html>

302

Trouve

La ressource cible reside temporairement sous un URI different. Comme la redirection peut etre modifiee a l'occasion, le client devrait continuer a utiliser l'URI d'origine pour les requetes futures.

Cas d'utilisation courants: Utilise pour les redirections temporaires, comme la redirection vers une page de connexion, l'envoi des utilisateurs vers une page de maintenance ou les tests A/B de differentes versions de page.

RFC 9110

Requête

GET /dashboard HTTP/1.1
Host: www.example.com

Réponse

HTTP/1.1 302 Found
Location: https://www.example.com/login?redirect=/dashboard

303

Voir autre

Le serveur redirige l'agent utilisateur vers une ressource differente avec une requete GET, generalement apres une operation POST. Cela garantit que le client ne soumet pas a nouveau les donnees du formulaire.

Cas d'utilisation courants: Utilise apres la soumission d'un formulaire POST pour rediriger vers une page de confirmation (le modele Post/Redirect/Get), empechant les soumissions de formulaire en double lorsque l'utilisateur actualise la page.

RFC 9110

304

Non modifie

La ressource n'a pas ete modifiee depuis la version specifiee par les en-tetes de requete If-Modified-Since ou If-None-Match. Le serveur n'a pas besoin de renvoyer le corps de la ressource.

Cas d'utilisation courants: Retourne lorsqu'un client effectue une requete conditionnelle et que la ressource n'a pas change, permettant au client d'utiliser sa copie en cache. Cela economise de la bande passante et ameliore les temps de chargement.

RFC 9110

Requête

GET /api/users/42 HTTP/1.1
Host: api.example.com
If-None-Match: "etag-abc123"

Réponse

HTTP/1.1 304 Not Modified
ETag: "etag-abc123"
Cache-Control: max-age=3600

307

Redirection temporaire

La ressource cible reside temporairement sous un URI different et l'agent utilisateur ne doit pas changer la methode de requete lors de la redirection. Contrairement a 302, la methode et le corps sont garantis de rester les memes.

Cas d'utilisation courants: Utilise lorsqu'une redirection temporaire est necessaire et doit strictement preserver la methode HTTP. Par exemple, rediriger une requete POST vers un autre point de terminaison sans la transformer en requete GET.

RFC 9110

308

Redirection permanente

La ressource cible s'est vu attribuer un nouveau URI permanent. Comme 301, mais la methode de requete et le corps ne doivent pas changer lors de la redirection.

Cas d'utilisation courants: Utilise pour les redirections permanentes lorsque la methode HTTP doit etre preservee. Par exemple, rediriger definitivement un point de terminaison POST tout en s'assurant que les clients continuent d'envoyer des requetes POST.

RFC 9110

4xx Erreur client

29 codes de statut

400

Mauvaise requete

Le serveur ne peut ou ne veut pas traiter la requete en raison de ce qui est percu comme une erreur du client, comme une syntaxe de requete malformee, un cadrage de requete invalide ou un routage de requete trompeur.

Cas d'utilisation courants: Retourne lorsque le corps de la requete contient du JSON malformee, que des champs obligatoires manquent, que les parametres de requete sont invalides ou que la requete ne se conforme pas au format attendu.

RFC 9110

Requête

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "",
  "email": "not-an-email"
}

Réponse

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "validation_error",
  "message": "Request validation failed",
  "details": [
    { "field": "name", "message": "Name is required" },
    { "field": "email", "message": "Must be a valid email address" }
  ]
}

401

Non autorise

La requete n'a pas ete appliquee car elle ne dispose pas d'identifiants d'authentification valides pour la ressource cible. La reponse doit inclure un en-tete WWW-Authenticate indiquant le schema d'authentification applicable.

Cas d'utilisation courants: Retourne lorsqu'une requete ne contient pas d'identifiants d'authentification ou que le jeton/les identifiants fournis sont expires ou invalides. Le client doit s'authentifier avant de reessayer.

RFC 9110

Requête

GET /api/users/me HTTP/1.1
Host: api.example.com

Réponse

HTTP/1.1 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: Bearer

{
  "error": "unauthorized",
  "message": "Authentication required. Please provide a valid Bearer token."
}

402

Paiement requis

Reserve pour un usage futur. Initialement prevu pour les systemes de paiement numerique, ce code de statut n'est pas largement standardise mais est parfois utilise par les API pour indiquer qu'un paiement est requis.

Cas d'utilisation courants: Bien qu'officiellement reserve, certaines API l'utilisent pour indiquer qu'une fonctionnalite payante ou un abonnement est requis, ou que l'utilisateur a depasse les limites de son forfait gratuit.

RFC 9110

403

Interdit

Le serveur a compris la requete mais refuse de l'autoriser. Contrairement a 401, l'authentification n'aidera pas. Le client ne dispose pas des permissions necessaires pour la ressource.

Cas d'utilisation courants: Retourne lorsque l'utilisateur est authentifie mais ne dispose pas des permissions requises. Par exemple, un utilisateur ordinaire essayant d'acceder a un point de terminaison reserve aux administrateurs, ou accedant a une ressource appartenant a un autre utilisateur.

RFC 9110

Requête

DELETE /api/users/99 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Réponse

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "forbidden",
  "message": "You do not have permission to delete this user. Admin role required."
}

404

Non trouve

Le serveur d'origine n'a pas trouve de representation actuelle pour la ressource cible ou n'est pas dispose a reveler qu'une telle representation existe. Cela peut etre temporaire ou permanent.

Cas d'utilisation courants: L'erreur la plus frequemment rencontree. Retournee lorsque la ressource demandee n'existe pas, comme la demande d'un utilisateur par un identifiant absent de la base de donnees, ou l'acces a une URL sans route correspondante.

RFC 9110

Requête

GET /api/users/99999 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Réponse

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "not_found",
  "message": "User with ID 99999 was not found"
}

405

Methode non autorisee

La methode recue dans la ligne de requete est connue du serveur d'origine mais n'est pas supportee par la ressource cible. La reponse doit inclure un en-tete Allow listant les methodes valides.

Cas d'utilisation courants: Retourne lorsque la methode HTTP n'est pas supportee pour le point de terminaison. Par exemple, l'envoi d'une requete DELETE a une ressource en lecture seule, ou un POST a un point de terminaison qui ne supporte que GET.

RFC 9110

Requête

DELETE /api/reports/monthly HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Réponse

HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Allow: GET, HEAD

{
  "error": "method_not_allowed",
  "message": "DELETE is not allowed on this resource. Allowed methods: GET, HEAD"
}

406

Non acceptable

La ressource cible ne dispose pas d'une representation qui serait acceptable pour l'agent utilisateur, selon les en-tetes de negociation de contenu proactive recus dans la requete.

Cas d'utilisation courants: Retourne lorsque le serveur ne peut pas produire une reponse correspondant aux en-tetes Accept envoyes par le client. Par exemple, un client demande du XML mais l'API ne supporte que le JSON.

RFC 9110

407

Authentification proxy requise

Similaire a 401, mais le client doit s'authentifier aupres du proxy. Le proxy doit retourner un en-tete Proxy-Authenticate avec le defi applicable.

Cas d'utilisation courants: Retourne par un serveur proxy lorsque le client n'a pas fourni d'identifiants valides pour le proxy lui-meme. Courant dans les environnements de reseau d'entreprise ou le trafic sortant passe par un proxy authentifie.

RFC 9110

408

Delai de requete depasse

Le serveur n'a pas recu de message de requete complet dans le delai qu'il etait pret a attendre. Le client peut repeter la requete sans modification ulterieurement.

Cas d'utilisation courants: Retourne lorsque le client met trop de temps a envoyer la requete complete. Peut se produire avec des connexions lentes, des telechargements volumineux sur des reseaux peu fiables, ou lorsqu'un client ouvre une connexion sans envoyer de donnees.

RFC 9110

409

Conflit

La requete n'a pas pu etre completee en raison d'un conflit avec l'etat actuel de la ressource cible. Le client devrait pouvoir resoudre le conflit et soumettre a nouveau la requete.

Cas d'utilisation courants: Utilise lorsqu'une requete entre en conflit avec des donnees existantes, comme la creation d'un utilisateur avec un e-mail deja existant, ou la tentative de mise a jour d'une ressource qui a ete modifiee par une autre requete depuis sa derniere recuperation.

RFC 9110

Requête

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}

Réponse

HTTP/1.1 409 Conflict
Content-Type: application/json

{
  "error": "conflict",
  "message": "A user with email jane@example.com already exists",
  "existing_id": 42
}

410

Disparu

La ressource cible n'est plus disponible sur le serveur d'origine et cette condition est probablement permanente. Contrairement a 404, cela indique explicitement que la ressource a existe mais a ete intentionnellement supprimee.

Cas d'utilisation courants: Utilise lorsqu'une ressource a ete deliberement et definitivement supprimee. Signale aux moteurs de recherche qu'ils devraient retirer l'URL de leur index, contrairement a 404 qui peut etre temporaire.

RFC 9110

411

Longueur requise

Le serveur refuse d'accepter la requete sans en-tete Content-Length defini. Le client peut repeter la requete si un en-tete Content-Length valide est ajoute.

Cas d'utilisation courants: Retourne lorsque le serveur exige la presence de l'en-tete Content-Length dans la requete, generalement pour les telechargements ou les requetes POST ou le serveur doit connaitre la taille de la charge utile a l'avance.

RFC 9110

412

Precondition echouee

Une ou plusieurs conditions donnees dans les champs d'en-tete de la requete ont ete evaluees a faux lors du test sur le serveur. Utilise avec les requetes conditionnelles comme If-Match ou If-Unmodified-Since.

Cas d'utilisation courants: Retourne lorsqu'une mise a jour conditionnelle echoue parce que la ressource a ete modifiee depuis la derniere recuperation par le client. Utilise pour implementer le controle de concurrence optimiste dans les API.

RFC 9110

413

Contenu trop volumineux

Le serveur refuse de traiter la requete car la charge utile est plus grande que ce que le serveur est dispose ou capable de traiter. Le serveur peut fermer la connexion ou retourner un en-tete Retry-After.

Cas d'utilisation courants: Retourne lorsqu'un telechargement de fichier ou un corps de requete depasse la taille maximale configuree du serveur, comme le telechargement d'un fichier de 100 Mo vers un point de terminaison avec une limite de 10 Mo.

RFC 9110

414

URI trop long

Le serveur refuse de traiter la requete car la cible de la requete est plus longue que ce que le serveur est dispose a interpreter. Cela peut se produire lorsqu'une requete GET a des parametres de requete excessivement longs.

Cas d'utilisation courants: Retourne lorsque l'URL depasse la longueur maximale du serveur. Cela se produit souvent lorsque trop de donnees sont encodees dans les parametres de requete au lieu d'etre envoyees dans un corps de requete POST.

RFC 9110

415

Type de media non supporte

Le serveur d'origine refuse de traiter la requete car la charge utile est dans un format non supporte par cette methode sur la ressource cible. Le Content-Type ou Content-Encoding n'est pas acceptable.

Cas d'utilisation courants: Retourne lorsque le serveur ne supporte pas le Content-Type envoye dans la requete. Par exemple, l'envoi de donnees form-urlencoded a un point de terminaison qui n'accepte que application/json.

RFC 9110

416

Plage non satisfaisable

L'ensemble des plages dans le champ d'en-tete Range de la requete a ete rejete car aucune des plages demandees n'est satisfaisable pour la representation selectionnee.

Cas d'utilisation courants: Retourne lorsqu'un client demande une plage d'octets qui depasse la taille de la ressource, comme la demande des octets 1000-2000 d'un fichier de 500 octets.

RFC 9110

417

Attente echouee

L'attente donnee dans le champ d'en-tete Expect de la requete n'a pas pu etre satisfaite par au moins un des serveurs entrants.

Cas d'utilisation courants: Retourne lorsque le serveur ne peut pas satisfaire les exigences specifiees dans l'en-tete Expect. Le plus souvent lie au mecanisme Expect: 100-continue lorsque le serveur rejette la requete avant l'envoi du corps.

RFC 9110

418

Je suis une theiere

Toute tentative de preparer du cafe avec une theiere devrait resulter en ce code d'erreur. Cela a ete defini dans le protocole Hyper Text Coffee Pot Control Protocol comme un poisson d'avril mais a ete preserve comme curiosite culturelle.

Cas d'utilisation courants: Un code de statut Easter egg provenant d'un RFC de poisson d'avril. Parfois utilise avec humour dans les API comme reponse amusante, ou comme refus delibere de traiter une requete que le serveur considere comme absurde.

RFC 2324

421

Requete mal dirigee

La requete a ete dirigee vers un serveur qui n'est pas en mesure de produire une reponse. Cela peut se produire lorsqu'un serveur n'est pas configure pour produire des reponses pour la combinaison de schema et d'autorite dans l'URI de la requete.

Cas d'utilisation courants: Peut se produire en HTTP/2 lorsqu'une connexion est reutilisee pour un nom d'hote different que le serveur ne peut pas gerer. Le client devrait reessayer la requete sur une connexion differente.

RFC 9110

422

Contenu non traitable

Le serveur comprend le type de contenu et la syntaxe de la requete est correcte, mais il n'a pas pu traiter les instructions contenues. La requete est bien formee mais semantiquement invalide.

Cas d'utilisation courants: Utilise lorsque le corps de la requete est du JSON syntaxiquement valide mais echoue a la validation de la logique metier. Par exemple, definir un prix negatif, planifier une reunion dans le passe ou fournir une date de fin anterieure a une date de debut.

RFC 9110

Requête

POST /api/events HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "title": "Team Meeting",
  "start_date": "2025-12-01",
  "end_date": "2025-11-01"
}

Réponse

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{
  "error": "unprocessable_entity",
  "message": "Semantic validation failed",
  "details": [
    { "field": "end_date", "message": "End date must be after start date" }
  ]
}

423

Verrouille

La ressource source ou de destination d'une methode est verrouillee. Le client devrait reessayer plus tard ou demander un deverrouillage.

Cas d'utilisation courants: Utilise dans WebDAV lorsqu'une ressource est verrouillee par un autre utilisateur ou processus. Peut egalement etre utilise dans les API pour indiquer qu'une ressource est temporairement verrouillee pour modification par un autre utilisateur.

RFC 4918

424

Echec de dependance

La methode n'a pas pu etre executee sur la ressource car l'action demandee dependait d'une autre action qui a echoue.

Cas d'utilisation courants: Utilise dans WebDAV lorsqu'une operation echoue parce qu'une operation prerequise dont elle depend a egalement echoue. Par exemple, la copie d'un repertoire echoue parce que la copie d'un des fichiers enfants a echoue.

RFC 4918

425

Trop tot

Le serveur n'est pas dispose a risquer le traitement d'une requete qui pourrait etre rejouee, afin d'eviter les attaques par rejeu potentielles lors de l'utilisation de TLS 1.3 early data (0-RTT).

Cas d'utilisation courants: Utilise lorsqu'une requete arrive dans les donnees anticipees TLS 1.3 (0-RTT) et que le serveur ne peut pas garantir qu'elle n'a pas deja ete traitee. Empeche les attaques par rejeu sur les requetes non idempotentes.

RFC 8470

426

Mise a niveau requise

Le serveur refuse d'executer la requete en utilisant le protocole actuel mais pourrait etre dispose a le faire apres que le client ait mis a niveau vers un protocole different. Le serveur doit inclure un en-tete Upgrade indiquant le protocole requis.

Cas d'utilisation courants: Utilise lorsque le serveur exige que le client passe a une version de protocole plus recente, comme la mise a niveau de HTTP/1.1 vers HTTP/2, ou d'une connexion non chiffree vers TLS.

RFC 9110

428

Precondition requise

Le serveur d'origine exige que la requete soit conditionnelle. Cela vise a prevenir le probleme de la mise a jour perdue ou un client recupere une ressource par GET, la modifie et la renvoie par PUT tandis qu'un autre client l'a egalement modifiee.

Cas d'utilisation courants: Retourne lorsque le serveur exige des en-tetes conditionnels comme If-Match ou If-Unmodified-Since pour prevenir les problemes de modification concurrente. Force les clients a implementer le verrouillage optimiste.

RFC 6585

429

Trop de requetes

L'utilisateur a envoye trop de requetes dans un laps de temps donne (limitation du debit). La reponse devrait inclure un en-tete Retry-After indiquant combien de temps attendre avant de faire une nouvelle requete.

Cas d'utilisation courants: Retourne lorsque le client depasse la limite de debit de l'API. La plupart des API utilisent cela pour se proteger contre les abus et assurer une utilisation equitable. Les clients devraient reculer et reessayer apres le delai specifie dans l'en-tete Retry-After.

RFC 6585

Requête

GET /api/search?q=test HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Réponse

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1735689600

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded. Maximum 100 requests per minute.",
  "retry_after": 60
}

431

Champs d'en-tete de requete trop grands

Le serveur n'est pas dispose a traiter la requete car ses champs d'en-tete sont trop grands. La requete peut etre soumise a nouveau apres avoir reduit la taille des champs d'en-tete de la requete.

Cas d'utilisation courants: Retourne lorsque les en-tetes de requete depassent les limites de taille du serveur. Cela se produit couramment lorsque les cookies deviennent trop volumineux, ou lorsque trop de donnees sont passees dans des en-tetes personnalises ou un jeton d'autorisation surdimensionne.

RFC 6585

451

Indisponible pour des raisons legales

Le serveur refuse l'acces a la ressource en consequence d'une exigence legale. La reponse devrait inclure une explication de la restriction legale dans le corps et un en-tete Link pour identifier l'autorite legale.

Cas d'utilisation courants: Utilise lorsqu'une ressource est bloquee en raison d'exigences legales telles que des ordonnances de censure gouvernementale, des avis de retrait DMCA, des decisions de justice ou la conformite aux sanctions. Le numero de code fait reference a Fahrenheit 451.

RFC 7725

5xx Erreur serveur

11 codes de statut

500

Erreur interne du serveur

Le serveur a rencontre une condition inattendue qui l'a empeche de satisfaire la requete. C'est une erreur generique fourre-tout lorsque aucun code de statut 5xx plus specifique n'est approprie.

Cas d'utilisation courants: L'erreur serveur la plus courante. Retournee lorsque le serveur rencontre une exception non geree, un bug, un echec de connexion a la base de donnees ou tout autre probleme inattendu lors du traitement de la requete.

RFC 9110

Réponse

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
  "error": "internal_server_error",
  "message": "An unexpected error occurred. Please try again later.",
  "request_id": "req_abc123xyz"
}

501

Non implemente

Le serveur ne supporte pas la fonctionnalite requise pour satisfaire la requete. C'est la reponse appropriee lorsque le serveur ne reconnait pas la methode de requete et n'est pas capable de la supporter.

Cas d'utilisation courants: Retourne lorsque le serveur ne reconnait pas ou n'a pas encore implemente la methode HTTP demandee. Peut etre utilise comme espace reserve pour les points de terminaison d'API qui sont planifies mais pas encore construits.

RFC 9110

502

Mauvaise passerelle

Le serveur, agissant en tant que passerelle ou proxy, a recu une reponse invalide d'un serveur en amont auquel il a accede pour tenter de satisfaire la requete.

Cas d'utilisation courants: Retourne par les proxys inverses, les equilibreurs de charge ou les passerelles API lorsque le serveur d'application en amont envoie une reponse malformee, plante ou est injoignable. Courant pendant les deployements.

RFC 9110

Réponse

HTTP/1.1 502 Bad Gateway
Content-Type: application/json

{
  "error": "bad_gateway",
  "message": "The upstream server returned an invalid response. Please try again shortly."
}

503

Service indisponible

Le serveur est actuellement incapable de traiter la requete en raison d'une surcharge temporaire ou d'une maintenance programmee. L'implication est que c'est une condition temporaire et que le serveur sera a nouveau disponible bientot.

Cas d'utilisation courants: Retourne pendant les fenetres de maintenance planifiees, lorsque le serveur est surcharge ou lorsqu'une dependance critique est en panne. L'en-tete Retry-After peut indiquer quand le client devrait reessayer.

RFC 9110

Réponse

HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 300

{
  "error": "service_unavailable",
  "message": "Service is temporarily unavailable for scheduled maintenance. Expected back at 2025-12-01T03:00:00Z.",
  "retry_after": 300
}

504

Delai de passerelle depasse

Le serveur, agissant en tant que passerelle ou proxy, n'a pas recu de reponse en temps opportun d'un serveur en amont auquel il devait acceder pour completer la requete.

Cas d'utilisation courants: Retourne par les proxys inverses ou les equilibreurs de charge lorsque le serveur d'application en amont met trop de temps a repondre. Indique souvent une requete de base de donnees lente, un delai d'attente d'API externe ou un backend surcharge.

RFC 9110

505

Version HTTP non supportee

Le serveur ne supporte pas, ou refuse de supporter, la version majeure de HTTP qui a ete utilisee dans le message de requete.

Cas d'utilisation courants: Retourne lorsque le serveur ne supporte pas la version du protocole HTTP utilisee dans la requete, comme un serveur qui ne supporte que HTTP/1.1 recevant une requete HTTP/2 qu'il ne peut pas gerer.

RFC 9110

506

La variante negocie egalement

Le serveur a une erreur de configuration interne : la ressource variante choisie est configuree pour s'engager elle-meme dans la negociation de contenu transparente, resultant en une reference circulaire.

Cas d'utilisation courants: Une erreur rare indiquant une mauvaise configuration dans la negociation de contenu cote serveur, ou la ressource negociee tente elle-meme de negocier, creant une boucle infinie.

RFC 2295

507

Stockage insuffisant

La methode n'a pas pu etre executee sur la ressource car le serveur est incapable de stocker la representation necessaire pour completer la requete avec succes.

Cas d'utilisation courants: Un statut WebDAV retourne lorsque le serveur manque d'espace disque ou de quota de stockage lors de la tentative d'ecriture de donnees. Peut egalement s'appliquer aux API ou une limite de stockage a ete atteinte.

RFC 4918

508

Boucle detectee

Le serveur a termine une operation car il a rencontre une boucle infinie lors du traitement d'une requete avec Depth: infinity. C'est une version plus specifique de 500.

Cas d'utilisation courants: Un statut WebDAV retourne lorsque le serveur detecte une dependance circulaire ou une boucle infinie dans les liaisons de ressources, comme une structure de repertoire qui se reference elle-meme.

RFC 5842

510

Non etendu

La politique d'acces a la ressource n'a pas ete satisfaite dans la requete. Le serveur devrait renvoyer toutes les informations necessaires pour que le client emette une requete etendue.

Cas d'utilisation courants: Un code de statut rarement utilise indiquant que des extensions supplementaires a la requete sont necessaires pour que le serveur la satisfasse. Defini dans la specification HTTP Extension Framework.

RFC 2774

511

Authentification reseau requise

Le client doit s'authentifier pour obtenir l'acces au reseau. Il ne s'agit pas d'authentification au niveau HTTP mais d'acces au niveau du reseau, comme la connexion a un portail captif.

Cas d'utilisation courants: Retourne par les portails captifs (par ex. les pages de connexion Wi-Fi d'hotel ou d'aeroport) lorsque l'utilisateur ne s'est pas encore authentifie aupres du reseau. Le corps de la reponse contient generalement une page de connexion.

RFC 6585

Guides associés

36 en-têtes

En-têtes HTTP

En-têtes HTTP courants expliqués avec syntaxe, exemples et valeurs courantes.

Parcourir

9 méthodes

Méthodes HTTP

Guide complet des méthodes de requête HTTP avec tableaux comparatifs et exemples.

Parcourir

70 types MIME

Types MIME

Référence complète des types MIME courants avec extensions de fichiers, catégories et exemples d'utilisation.

Parcourir

10 en-têtes

CORS expliqué

Guide complet du partage de ressources entre origines — fonctionnement, chaque en-tête expliqué et erreurs courantes avec solutions.

Parcourir

Essayez dans RequestDock

Envoyez de vraies requêtes HTTP et inspectez les réponses — directement dans votre navigateur.

Ouvrir RequestDock