Tous les produits
Search
Centre de documentation

OpenAPI Explorer:Codes d'état HTTP

Dernière mise à jour :Sep 08, 2026

L'IETF définit les codes d'état HTTP dans la RFC 9110 et les enregistre auprès de l'IANA. Les API OpenAPI d'Alibaba Cloud suivent généralement cette norme.

Conventions relatives aux codes d'état dans les API OpenAPI d'Alibaba Cloud

Les API OpenAPI d'Alibaba Cloud suivent généralement la norme des codes d'état HTTP décrite dans cette rubrique : un code 2xx indique un appel réussi, un code 4xx signale un problème côté client (tel qu'un paramètre invalide, un échec d'authentification, des autorisations insuffisantes ou un quota dépassé) et un code 5xx indique un problème côté serveur. En cas d'échec, les appels renvoient généralement aussi les champs Code et Message pour un diagnostic plus précis, ainsi qu'un RequestId qui identifie l'appel de manière unique.

Remarque

La sémantique exacte et les conditions de déclenchement d'un code d'état peuvent varier selon le service cloud. Lorsque vous appelez une opération d'API OpenAPI, reportez-vous à la référence d'API actuelle de ce service.

Structure et classes

Un code d'état est un entier à trois chiffres qui décrit le résultat d'une requête et la sémantique de la réponse. Les valeurs valides vont de 100 à 599. Le premier chiffre définit la classe de la réponse ; les deux derniers n'ont aucun rôle de catégorisation.

Classe

Signification

1xx (Information)

Le serveur a reçu la requête et le traitement se poursuit. Il s'agit de réponses intermédiaires : une seule requête peut générer zéro ou plusieurs réponses 1xx avant exactement une réponse finale.

2xx (Succès)

Le serveur a reçu, compris et accepté la requête avec succès.

3xx (Redirection)

Le client doit effectuer une action supplémentaire pour terminer la requête.

4xx (Erreur client)

La syntaxe de la requête est incorrecte ou elle ne peut pas être satisfaite. La faute incombe généralement à l'appelant.

5xx (Erreur serveur)

Le serveur n'a pas pu satisfaire une requête apparemment valide. La faute incombe au serveur.

Codes d'état enregistrés

Les tableaux suivants répertorient la signification standard de chaque code et la spécification qui le définit.

Informations 1xx

Une réponse 1xx se termine à la fin de la section d'en-tête et ne peut contenir ni corps ni trailers. Étant donné que HTTP/1,0 ne définissait aucun code 1xx, un serveur ne doit pas envoyer de réponse 1xx à un client HTTP/1,0.

Code

Nom standard

Signification

Défini dans

100

Continue

Le serveur a reçu la partie initiale de la requête sans la rejeter et est prêt à accepter le contenu de la requête. Continuez à envoyer le corps et ignorez cette réponse intermédiaire.

RFC 9110

101

Switching Protocols

Le serveur accepte le changement de protocole demandé via l'en-tête Upgrade et indique les protocoles qui entrent en vigueur dans son propre en-tête Upgrade.

RFC 9110

102

Processing

Défini par l'extension WebDAV et désormais obsolète. Évitez de l'utiliser dans les nouvelles conceptions.

RFC 2518

103

Early Hints

Renvoie certains en-têtes, généralement Link, avant la réponse finale afin que le client puisse commencer à précharger les ressources.

RFC 8297

Succès 2xx

Code

Nom standard

Signification

Défini dans

200

OK

La requête a réussi. Le contenu de la réponse dépend de la méthode : GET renvoie une représentation de la ressource cible, POST renvoie l'état ou les résultats de l'action, PUT et DELETE renvoient l'état de l'action, et OPTIONS renvoie les options de communication.

RFC 9110

201

Created

La requête a été satisfaite et une ou plusieurs nouvelles ressources ont été créées. L'en-tête Location identifie la ressource principale, ou l'URI cible si aucun en-tête Location n'est envoyé.

RFC 9110

202

Accepted

Le serveur a accepté la requête pour traitement, mais celui-ci n'est pas terminé et pourrait finalement être refusé. HTTP ne dispose d'aucun mécanisme pour renvoyer un code d'état depuis une opération asynchrone ; la réponse pointe donc généralement vers une ressource d'état interrogeable.

RFC 9110

203

Non-Authoritative Information

La requête a réussi, mais un proxy de transformation a modifié le contenu, qui diffère donc de ce que le serveur d'origine aurait renvoyé dans une réponse 200.

RFC 9110

204

No Content

La requête a été satisfaite et il n'y a aucun contenu supplémentaire à envoyer dans le corps de la réponse. Les métadonnées peuvent toujours figurer dans les en-têtes de réponse.

RFC 9110

205

Reset Content

La requête a été satisfaite et le client doit réinitialiser la vue du document qui a provoqué la requête, par exemple en effaçant un formulaire.

RFC 9110

206

Partial Content

Le serveur a satisfait une requête de plage et a renvoyé une ou plusieurs parties de la ressource cible. Ce code est courant dans les transferts reprenables et les téléchargements fragmentés de fichiers volumineux.

RFC 9110

207

Multi-Status

Défini par l'extension WebDAV. Le corps contient un statut distinct pour chaque sous-opération.

RFC 4918

208

Already Reported

Défini par l'extension de liaison WebDAV. Évite d'énumérer plusieurs fois la même ressource au sein d'une seule réponse.

RFC 5842

226

IM Used

Le serveur a appliqué un ou plusieurs encodages delta à la ressource cible et a renvoyé le delta plutôt que la ressource complète.

RFC 3229

Redirection 3xx

Les codes 301, 302, 307 et 308 indiquent tous que la ressource se trouve à une autre URI. Ils diffèrent selon que le déplacement est permanent et si la méthode de requête peut changer. Pour des raisons historiques, les clients gérant les codes 301 et 302 peuvent transformer une requête POST en GET. Utilisez plutôt 308 et 307 lorsque la méthode doit être préservée.

Code

Nom standard

Signification

Défini dans

300

Multiple Choices

La ressource cible possède plusieurs représentations et le client ou l'utilisateur doit choisir parmi elles.

RFC 9110

301

Moved Permanently

La ressource cible a reçu une nouvelle URI permanente que les références futures doivent utiliser. Le serveur doit envoyer la nouvelle URI dans l'en-tête Location.

RFC 9110

302

Found

La ressource cible réside temporairement à une URI différente. Étant donné que la redirection peut changer, continuez à utiliser l'URI d'origine pour les requêtes futures.

RFC 9110

303

See Other

Le serveur redirige le client vers une autre ressource pour répondre indirectement à la requête. Émettez une requête GET ou HEAD vers l'URI indiquée dans l'en-tête Location et présentez ce résultat comme la réponse. La nouvelle URI n'est pas équivalente à l'URI cible.

RFC 9110

304

Not Modified

Une condition préalable sur un GET ou HEAD conditionnel a été évaluée comme fausse, ce qui signifie que le client détient déjà une représentation valide. Le serveur évite la retransmission et le client peut utiliser sa copie mise en cache. La réponse ne peut contenir aucun contenu.

RFC 9110

305

Use Proxy

Obsolète. Ne pas utiliser dans les nouvelles implémentations.

RFC 9110

306

(Unused)

Défini dans une version antérieure de la spécification, ce code n'est plus utilisé et est réservé.

RFC 9110

307

Temporary Redirect

La ressource cible réside temporairement à une URI différente et le client ne doit pas modifier la méthode de requête lors du suivi automatique de la redirection.

RFC 9110

308

Permanent Redirect

Présente la même sémantique que 301 mais oblige le client à préserver la méthode de requête. Défini en 2014, plus tardivement que ses codes frères, certaines implémentations héritées peuvent ne pas le reconnaître.

RFC 9110

Erreur client 4xx

Sauf lors de la réponse à une requête HEAD, le serveur doit expliquer l'erreur dans le corps de la réponse et indiquer si la condition est temporaire ou permanente. Ces codes s'appliquent à toute méthode de requête.

Code

Nom standard

Signification

Défini dans

400

Bad Request

Le serveur ne traitera pas la requête en raison d'une erreur client perçue, telle qu'une syntaxe mal formée, un cadrage de message invalide ou un routage trompeur.

RFC 9110

401

Unauthorized

La requête manque d'identifiants d'authentification valides pour la ressource cible. Le serveur doit envoyer un en-tête WWW-Authenticate nommant un défi applicable. Si des identifiants ont été fournis, ils ont été refusés.

RFC 9110

402

Payment Required

Réservé pour une utilisation future.

RFC 9110

403

Forbidden

Le serveur a compris la requête mais refuse de la satisfaire. Si des identifiants ont été fournis, le serveur les considère comme insuffisants et le client ne doit pas réessayer automatiquement avec les mêmes identifiants.

RFC 9110

404

Not Found

Le serveur d'origine n'a trouvé aucune représentation actuelle de la ressource cible, ou ne souhaite pas divulguer son existence.

RFC 9110

405

Method Not Allowed

La ressource cible ne prend pas en charge la méthode de requête. Le serveur doit envoyer un en-tête Allow listant les méthodes prises en charge.

RFC 9110

406

Not Acceptable

La ressource cible ne possède aucune représentation qui satisfait les en-têtes de négociation de contenu de la requête.

RFC 9110

407

Proxy Authentication Required

Similaire à 401, mais le client doit s'authentifier auprès du proxy plutôt qu'auprès du serveur d'origine.

RFC 9110

408

Request Timeout

Le serveur n'a pas reçu de requête complète dans le délai qu'il était prêt à attendre.

RFC 9110

409

Conflict

La requête entre en conflit avec l'état actuel de la ressource cible.

RFC 9110

410

Gone

La ressource cible n'est plus disponible sur le serveur d'origine et la condition est probablement permanente.

RFC 9110

411

Length Required

Le serveur nécessite un en-tête Content-Length dans la requête.

RFC 9110

412

Precondition Failed

Une ou plusieurs conditions préalables dans les en-têtes de requête ont été évaluées comme fausses sur le serveur.

RFC 9110

413

Content Too Large

Le corps de la requête est plus volumineux que ce que le serveur est prêt ou capable de traiter.

RFC 9110

414

URI Too Long

L'URI cible de la requête est plus longue que ce que le serveur est prêt à interpréter.

RFC 9110

415

Unsupported Media Type

La ressource cible ne prend pas en charge le format de contenu du corps de la requête.

RFC 9110

416

Range Not Satisfiable

Les plages dans l'en-tête Range ne chevauchent pas l'étendue actuelle de la ressource, ou l'ensemble de plages est autrement invalide.

RFC 9110

417

Expectation Failed

Le serveur n'a pas pu satisfaire l'attente indiquée dans l'en-tête Expect.

RFC 9110

418

(Unused)

Auparavant utilisé par un brouillon de protocole informel. Réservé, aucune nouvelle sémantique ne peut lui être attribuée.

RFC 9110

421

Misdirected Request

La requête a été dirigée vers un serveur qui ne peut pas produire de réponse faisant autorité pour l'URI cible.

RFC 9110

422

Unprocessable Content

Le type de média et la syntaxe du corps de la requête ont été compris, mais les instructions sémantiques qu'il contient ne peuvent pas être traitées.

RFC 9110

423

Locked

Défini par l'extension WebDAV. La ressource cible est verrouillée.

RFC 4918

424

Failed Dependency

Défini par l'extension WebDAV. Une action dont dépend cette requête n'a pas abouti.

RFC 4918

425

Too Early

Le serveur ne souhaite pas traiter une requête rejouée dans les données TLS précoces. Réessayez après la fin du handshake.

RFC 8470

426

Upgrade Required

Le serveur refuse la requête sur le protocole actuel mais peut l'accepter après la mise à niveau du client. La réponse doit inclure un en-tête Upgrade.

RFC 9110

428

Precondition Required

Le serveur exige que la requête soit conditionnelle, ce qui empêche les mises à jour concurrentes de s'écraser mutuellement.

RFC 6585

429

Too Many Requests

Le client a envoyé plus de requêtes que la limite de débit ne le permet sur une période donnée. La réponse peut contenir un en-tête Retry-After avec le temps d'attente suggéré.

RFC 6585

431

Request Header Fields Too Large

Un champ d'en-tête individuel, ou la section d'en-tête dans son ensemble, dépasse la taille que le serveur traitera.

RFC 6585

451

Unavailable For Legal Reasons

Le serveur refuse l'accès à la ressource en réponse à une exigence légale.

RFC 7725

Erreur serveur 5xx

Code

Nom standard

Signification

Défini dans

500

Internal Server Error

Le serveur a rencontré une condition inattendue qui l'a empêché de satisfaire la requête.

RFC 9110

501

Not Implemented

Le serveur ne prend pas en charge la fonctionnalité requise pour satisfaire la requête, généralement parce qu'il ne reconnaît pas la méthode.

RFC 9110

502

Bad Gateway

Un serveur agissant en tant que passerelle ou proxy a reçu une réponse invalide d'un serveur amont.

RFC 9110

503

Service Unavailable

Le serveur ne peut pas gérer la requête en raison d'une surcharge temporaire ou d'une maintenance planifiée. La condition est transitoire et la réponse peut contenir un en-tête Retry-After.

RFC 9110

504

Gateway Timeout

Un serveur agissant en tant que passerelle ou proxy n'a pas reçu de réponse rapide d'un serveur amont.

RFC 9110

505

HTTP Version Not Supported

Le serveur ne prend pas en charge, ou refuse de prendre en charge, la version majeure HTTP utilisée dans la requête.

RFC 9110

506

Variant Also Negotiates

Défini par l'extension de négociation de contenu transparente. Indique une erreur de configuration interne sur le serveur.

RFC 2295

507

Insufficient Storage

Défini par l'extension WebDAV. Le serveur ne peut pas allouer suffisamment de stockage pour terminer la requête.

RFC 4918

508

Loop Detected

Défini par l'extension de liaison WebDAV. Le serveur a détecté une boucle infinie lors du traitement de la requête.

RFC 5842

510

Not Extended

La définition originale a été rendue obsolète. Le code reste enregistré, mais sa sémantique ne s'applique plus.

RFC 2774

511

Network Authentication Required

Le client doit s'authentifier pour obtenir un accès réseau, comme avec le portail captif d'un réseau Wi-Fi public.

RFC 6585

Références