Référence des Codes de Statut HTTP
Référence complète des codes de statut HTTP. Recherchez la signification de tout code de statut, comprenez les codes de réponse et apprenez-en sur les codes d'erreur HTTP.
Continue
The server has received the request headers and the client should proceed to send the request body.
Switching Protocols
The requester has asked the server to switch protocols and the server has agreed.
Processing
A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request.
Early Hints
Used to return some response headers before final HTTP message.
OK
The request is successful. The meaning of success depends on the HTTP method used.
Created
The request has been fulfilled and a new resource has been created.
Accepted
The request has been accepted for processing, but the processing has not been completed.
Non-Authoritative Information
The request was successful but the information may have been modified by a transforming proxy.
No Content
The server successfully processed the request but is not returning any content.
Reset Content
The server successfully processed the request but is not returning any content and requires the requester to reset the document view.
Partial Content
The server is delivering only part of the resource due to a range header sent by the client.
Multi-Status
Provides status for multiple independent operations.
Already Reported
The members of a DAV binding have already been enumerated in a preceding part of the multistatus response.
IM Used
The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.
Multiple Choices
The request has more than one possible response. The user agent should choose one of them.
Moved Permanently
The URL of the requested resource has been changed permanently. The new URL is given in the response.
Found
The URL of the requested resource has been changed temporarily. Further changes in the URL might be made in the future.
See Other
The server sent this response to direct the client to get the requested resource at another URI with a GET request.
Not Modified
Used for caching purposes. The client can use cached version of the response.
Use Proxy
The requested resource is available only through a proxy.
Unused
This response code is no longer used and is reserved.
Temporary Redirect
The server sends this response to direct the client to get the requested resource at another URI with the same method.
Permanent Redirect
This means the resource is now permanently located at another URI.
Bad Request
The server could not understand the request due to invalid syntax.
Unauthorized
Authentication is required and has failed or has not yet been provided.
Payment Required
This response code is reserved for future use and was originally created for digital payment systems.
Forbidden
The client does not have access rights to the content; the server is refusing to give the requested resource.
Not Found
The server can not find the requested resource. This is the most common error on the internet.
Method Not Allowed
The request method is known by the server but is not supported by the target resource.
Not Acceptable
The server cannot produce a response matching the list of acceptable values defined in the request's headers.
Proxy Authentication Required
This is similar to 401 but authentication is required to be done by a proxy.
Request Timeout
The server timed out waiting for the request. The client did not produce a request within the time the server was prepared to wait.
Conflict
This response is sent when a request conflicts with the current state of the server.
Gone
The requested content has been permanently deleted from the server with no forwarding address.
Length Required
The server rejects the request because the Content-Length header field is not defined and the server requires it.
Precondition Failed
The client has indicated preconditions in its headers which the server does not meet.
Payload Too Large
The request entity is larger than limits defined by the server.
URI Too Long
The URI requested by the client is longer than the server is willing to interpret.
Unsupported Media Type
The media format of the requested data is not supported by the server.
Range Not Satisfiable
The range specified by the Range header field in the request cannot be fulfilled.
Expectation Failed
The expectation indicated by the Expect request header field cannot be met by the server.
I'm a teapot
This code was defined in 1998 as one of the traditional IETF April Fools' jokes.
Misdirected Request
The request was directed at a server that is not able to produce a response.
Unprocessable Entity
The request was well-formed but was unable to be followed due to semantic errors.
Locked
The resource that is being accessed is locked.
Failed Dependency
The request failed because it depended on another request and that request failed.
Too Early
Indicates that the server is unwilling to risk processing a request that might be replayed.
Upgrade Required
The server refuses to perform the request using the current protocol.
Precondition Required
The origin server requires the request to be conditional.
Too Many Requests
The user has sent too many requests in a given amount of time.
Request Header Fields Too Large
The server is unwilling to process the request because its header fields are too large.
Unavailable For Legal Reasons
The server is denying access to the resource as a consequence of a legal demand.
Internal Server Error
The server has encountered a situation it does not know how to handle.
Not Implemented
The request method is not supported by the server and cannot be handled.
Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from an upstream server.
Service Unavailable
The server is not ready to handle the request. Common causes are a server that is down for maintenance or is overloaded.
Gateway Timeout
The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
HTTP Version Not Supported
The HTTP version used in the request is not supported by the server.
Variant Also Negotiates
The server has an internal configuration error.
Insufficient Storage
The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.
Loop Detected
The server detected an infinite loop while processing the request.
Not Extended
Further extensions to the request are required for the server to fulfill it.
Network Authentication Required
The client needs to authenticate to gain network access.
Comment Utiliser la Référence des Codes de Statut HTTP
Notre outil de référence des codes de statut HTTP fournit une référence complète pour tous les codes de statut HTTP. Utilisez-le pour trouver rapidement des informations sur n'importe quel code de statut:
- Recherchez des codes de statut en entrant un numéro de code (comme '404'), un nom de statut (comme 'not found') ou des mots-clés de description
- Filtrez par catégorie en utilisant les boutons de catégorie pour afficher uniquement les codes informationnels, de succès, de redirection, d'erreur client ou d'erreur serveur
- Cliquez sur n'importe quelle carte de code de statut pour l'étendre et voir des informations détaillées incluant la description, les cas d'usage courants et la référence RFC
- Utilisez le bouton de copie pour copier les codes de statut à utiliser dans la documentation, les commentaires de code ou les spécifications d'API
For more developer tools, check out our Toolbox homepage or explore related tools like our JSON Formatter and Hash Generator for API development workflows.
Qu'est-ce que les Codes de Statut HTTP?
La recherche de codes de statut HTTP est essentielle pour les développeurs web, les concepteurs d'API et toute personne travaillant avec des technologies web. Les codes de statut HTTP sont des nombres à trois chiffres renvoyés par les serveurs web pour indiquer le résultat d'une requête HTTP. Ces codes fournissent des informations critiques sur si une requête a réussi, si une erreur s'est produite ou si une action supplémentaire est nécessaire.
Lorsque vous visitez un site web ou effectuez un appel API, le serveur répond avec un code de statut HTTP ainsi que la ressource demandée ou un message d'erreur. Les codes de statut sont regroupés en cinq catégories principales basées sur leur premier chiffre: réponses informationnelles (1xx), réponses de succès (2xx), redirections (3xx), erreurs client (4xx) et erreurs serveur (5xx). Comprendre ces codes aide les développeurs à déboguer les problèmes, à implémenter une gestion d'erreurs appropriée et à créer de meilleures expériences utilisateur.
Connaître les codes de statut HTTP est crucial pour créer des applications web et des API robustes. L'utilisation appropriée des codes de statut améliore la gestion des erreurs, permet un meilleur débogage, améliore la documentation de l'API et aide à créer des messages d'erreur plus intuitifs pour les utilisateurs finaux. Notre outil de référence des codes de statut HTTP fournit une référence complète pour tous les codes de statut standard et étendus.
The official HTTP status code specifications are defined in RFC 7231 and related RFC documents maintained by the Internet Engineering Task Force (IETF). For comprehensive documentation, refer to the MDN HTTP Status Codes reference.
Catégories de Codes de Statut HTTP
Les codes de statut HTTP sont organisés en cinq catégories principales. Chaque catégorie sert un objectif spécifique dans la communication HTTP:
1xx Informational Responses
Les réponses informationnelles (100-199) indiquent que la requête a été reçue et que le processus se poursuit. Ce sont des réponses provisoires utilisées pendant la phase de traitement de la requête. Les exemples incluent 100 Continue, qui indique au client de continuer à envoyer le corps de la requête, et 101 Switching Protocols, utilisé lors de la mise à niveau vers un protocole différent comme WebSocket.
2xx Success Responses
Les réponses de succès (200-299) indiquent que la requête a été reçue, comprise et acceptée avec succès. Le code de succès le plus courant est 200 OK, ce qui signifie que la requête a réussi. D'autres codes de succès importants incluent 201 Created (pour la création de ressources), 204 No Content (pour les opérations réussies sans corps de réponse) et 206 Partial Content (pour les requêtes de plage dans les téléchargements de fichiers).
3xx Redirection Responses
Les réponses de redirection (300-399) indiquent qu'une action supplémentaire doit être entreprise pour terminer la requête. Ces codes sont utilisés lorsqu'une ressource a été déplacée ou lorsque des emplacements alternatifs doivent être utilisés. Les codes de redirection courants incluent 301 Moved Permanently (pour les changements d'URL permanents et le SEO), 302 Found (redirection temporaire) et 304 Not Modified (pour l'optimisation du cache).
4xx Client Error Responses
Les réponses d'erreur client (400-499) indiquent qu'il y a eu une erreur avec la requête. Ces erreurs sont de la responsabilité du client, ce qui signifie que la requête était mal formée, non autorisée ou que la ressource demandée n'existe pas. L'erreur client la plus célèbre est 404 Not Found. D'autres codes importants incluent 400 Bad Request (syntaxe invalide), 401 Unauthorized (authentification requise), 403 Forbidden (permission refusée) et 429 Too Many Requests (limitation de débit).
5xx Server Error Responses
Les réponses d'erreur serveur (500-599) indiquent que le serveur n'a pas pu satisfaire une requête valide. Ces erreurs sont de la responsabilité du serveur et indiquent souvent des problèmes avec la configuration du serveur, la base de données ou la logique de l'application. Les erreurs serveur courantes incluent 500 Internal Server Error (échec générique du serveur), 502 Bad Gateway (réponse invalide du serveur en amont), 503 Service Unavailable (serveur temporairement indisponible) et 504 Gateway Timeout (délai d'attente du serveur en amont).
Codes de Statut HTTP les Plus Courants Expliqués
Bien qu'il existe des dizaines de codes de statut HTTP, certains codes sont rencontrés plus fréquemment dans le développement web. Comprendre ces codes courants est essentiel pour un débogage et une gestion d'erreurs efficaces:
200 OK
200 OK est la réponse de succès standard pour les requêtes HTTP. Il indique que la requête a réussi et que la réponse contient la ressource demandée. C'est le code de statut le plus courant que vous rencontrerez dans les appels API réussis et les chargements de pages web. Le corps de la réponse contient généralement les données demandées, HTML, JSON ou d'autres types de contenu.
201 Created
201 Created indique qu'une nouvelle ressource a été créée avec succès à la suite de la requête. Ce code est généralement utilisé en réponse aux requêtes POST qui créent de nouvelles ressources. La réponse inclut généralement un en-tête Location pointant vers la ressource nouvellement créée. C'est une pratique standard dans la conception d'API RESTful pour les points de terminaison de création de ressources.
301 Moved Permanently
301 Moved Permanently indique que la ressource demandée a été déplacée de façon permanente vers une nouvelle URL. C'est crucial pour le SEO, car les moteurs de recherche mettront à jour leurs index pour pointer vers le nouvel emplacement. Lors de l'implémentation de redirections 301, assurez-vous toujours que la nouvelle URL est correcte, car les navigateurs et les moteurs de recherche mettront en cache cette redirection de façon permanente. Utilisez ceci pour les changements d'URL permanents, les migrations de domaine ou lors de la consolidation de contenu en double.
404 Not Found
404 Not Found est peut-être le code de statut HTTP le plus reconnaissable. Il indique que le serveur ne peut pas trouver la ressource demandée. Cela ne signifie pas que la ressource est partie de façon permanente (ce serait 410 Gone), mais plutôt qu'elle n'existe pas à l'emplacement spécifié. Les causes courantes incluent des liens cassés, des pages supprimées, des URL incorrectes ou des fichiers manquants. Lors de l'implémentation de pages d'erreur, fournissez toujours des options de navigation utiles et une fonctionnalité de recherche pour aider les utilisateurs à trouver ce qu'ils recherchent.
500 Internal Server Error
500 Internal Server Error est une erreur serveur générique indiquant que quelque chose s'est mal passé côté serveur, mais le serveur n'a pas pu être plus spécifique sur ce qu'était le problème. Ce code doit être utilisé lorsqu'une condition inattendue s'est produite qui a empêché le serveur de satisfaire la requête. Il est important de consigner ces erreurs sur le serveur à des fins de débogage, car elles indiquent des problèmes qui doivent être résolus dans le code de l'application ou la configuration du serveur.
Codes de Statut HTTP dans le Développement d'API
L'utilisation appropriée des codes de statut HTTP est fondamentale pour créer des API REST bien conçues. Les codes de statut communiquent le résultat des opérations API de manière claire et cohérente, rendant les API plus faciles à comprendre et à intégrer:
- Cohérence: Utiliser des codes de statut appropriés de manière cohérente dans votre API aide les développeurs à comprendre et à intégrer votre API plus facilement. Suivez les conventions REST et les normes HTTP pour assurer un comportement prévisible.
- Gestion des Erreurs: Différents codes de statut aident les applications clientes à gérer les erreurs de manière appropriée. Les erreurs 4xx indiquent des problèmes côté client que le client peut potentiellement corriger (comme une entrée invalide), tandis que les erreurs 5xx indiquent des problèmes côté serveur qui nécessitent une intervention du serveur.
- Documentation: Documenter quels codes de statut vos points de terminaison API peuvent renvoyer aide les développeurs à implémenter une gestion d'erreurs appropriée. Incluez les codes de statut dans votre documentation API, les spécifications OpenAPI et les exemples de code.
- Expérience Client: Des codes de statut bien choisis améliorent l'expérience client en fournissant des informations claires et exploitables. Par exemple, une réponse 429 Too Many Requests avec un en-tête Retry-After donne aux clients des conseils spécifiques sur quand réessayer leur requête.
Meilleures Pratiques pour les Codes de Statut HTTP
Suivre les meilleures pratiques pour les codes de statut HTTP améliore la fiabilité, la maintenabilité et la facilité d'utilisation des applications web et des API:
- Choisissez des Codes Appropriés: Sélectionnez des codes de statut qui reflètent avec précision le résultat de la requête. N'utilisez pas 200 OK pour les conditions d'erreur ou 500 pour les erreurs client. Utilisez le code le plus spécifique qui décrit avec précision la situation.
- Fournissez des Détails d'Erreur: Lors du renvoi de codes de statut d'erreur (4xx, 5xx), incluez des messages d'erreur détaillés dans le corps de la réponse. Cela aide les développeurs à déboguer les problèmes et fournit de meilleures capacités de gestion d'erreurs. Incluez les codes d'erreur, les descriptions et potentiellement des solutions suggérées.
- Journalisation et Surveillance: Enregistrez tous les codes de statut non 2xx à des fins de surveillance et de débogage. Suivez les taux d'erreur, identifiez les modèles et configurez des alertes pour les pics d'erreur inhabituels. Cela aide à identifier les problèmes avant qu'ils n'affectent significativement les utilisateurs.
- Surveillance: Utilisez la surveillance des codes de statut pour suivre la santé de l'application. Des taux élevés d'erreurs 5xx indiquent des problèmes serveur, tandis que des taux élevés d'erreurs 4xx peuvent indiquer des problèmes côté client, une mauvaise utilisation de l'API ou des problèmes de documentation qui nécessitent une attention.
Dépannage des Problèmes Courants de Codes de Statut
Comprendre comment résoudre les problèmes basés sur les codes de statut HTTP est une compétence essentielle pour les développeurs web et les administrateurs système:
Erreurs Client (4xx): Lors de la rencontre d'erreurs 4xx, vérifiez le format de la requête, les identifiants d'authentification, les permissions d'autorisation et si la ressource demandée existe. Examinez les en-têtes de requête, les paramètres de requête et le format du corps de la requête. Les corrections courantes incluent la correction des URL, la fourniture d'une authentification appropriée, la correction de la syntaxe de la requête et l'assurance que les ressources existent.
Pour 400 Bad Request, validez les données d'entrée et vérifiez le format de la requête. Pour 401 Unauthorized, vérifiez les jetons d'authentification ou les identifiants. Pour 403 Forbidden, vérifiez les permissions utilisateur et les règles d'autorisation. Pour 404 Not Found, vérifiez l'URL de la ressource et son existence. Pour 429 Too Many Requests, implémentez la limitation de débit ou attendez avant de réessayer.
Erreurs Serveur (5xx): Les erreurs 5xx indiquent des problèmes côté serveur qui nécessitent une enquête. Vérifiez les journaux du serveur, la connectivité de la base de données, le code de l'application, la configuration du serveur et les ressources système. Ces erreurs nécessitent généralement l'intervention d'un développeur ou d'un administrateur système pour être résolues.
Pour 500 Internal Server Error, vérifiez les journaux de l'application pour les exceptions, vérifiez les connexions à la base de données et examinez les changements de code récents. Pour 502 Bad Gateway, vérifiez l'état de santé du serveur en amont et la configuration du proxy. Pour 503 Service Unavailable, vérifiez la capacité du serveur, vérifiez les opérations de maintenance et examinez les contraintes de ressources. Pour 504 Gateway Timeout, vérifiez les temps de réponse du serveur en amont et les configurations de délai d'attente.