HTTP 201 Created : ce que cela signifie

Ce que signifie cette erreur et comment la reconnaître

• Un client API, une application exécutée dans un navigateur, un outil de monitoring ou un vérificateur signale 201 Created.
• La réponse peut inclure un objet nouvellement créé, des métadonnées de ressource ou un en-tête Location.
• Le résultat peut se produire uniquement pour une route, une méthode HTTP, un compte ou un payload de requête spécifique.
• Une réponse 201 réussie peut être accompagnée d’avertissements au niveau de l’application ou de détails de validation dans le corps de la réponse.
• Les contrôles DNS et TLS peuvent tout de même réussir, car un endpoint capable de communiquer en HTTP a renvoyé une réponse ; ces contrôles sont distincts du statut HTTP.

Causes principales, classées par probabilité

1. Création de ressource attendue : La route crée intentionnellement un enregistrement, un compte, un upload, une tâche, une commande ou une autre ressource, puis renvoie 201 une fois l’opération réussie.
2. Une méthode créant une ressource a été utilisée : Le client a envoyé une requête POST ou PUT vers un endpoint conçu pour créer une ressource. La méthode et la route déterminent si 201 est approprié.
3. La requête a été répétée ou envoyée vers la mauvaise route : Un client, une intégration ou un formulaire peut cibler un endpoint de création alors qu’il devrait mettre à jour une ressource existante ou utiliser une autre URL.
4. Le comportement de l’application ou du routage a changé : Un déploiement, un contrôleur, un handler ou une règle de routage peut avoir modifié le statut renvoyé pour une requête.
5. Un intermédiaire a généré ou modifié la réponse : Un reverse proxy, un CDN, un WAF ou une gateway peut être impliqué, notamment lorsque les en-têtes diffèrent entre les requêtes directes et publiques.
6. L’interprétation du client est trompeuse : Une règle de monitoring peut classer toute réponse HTTP sans erreur comme inhabituelle, alors que 201 est valide pour cet endpoint.

Comment corriger le problème

Commencez par déterminer si HTTP 201 est attendu

1. Notez l’URL exacte, la méthode HTTP, le corps de la requête ou les paramètres pertinents, le contexte du compte et l’horodatage. N’incluez pas de mots de passe, cookies, jetons d’accès ni autres secrets dans les notes partagées.
2. Consultez le comportement documenté de l’endpoint ou le contrat de l’application. Un endpoint de création renvoie généralement 201 ; une requête vers une page en lecture seule ne devrait normalement pas créer de ressource.
3. Examinez le corps et les en-têtes de la réponse. Recherchez un en-tête Location, un identifiant de ressource, le type de contenu, un identifiant de requête, les informations de cache et tout avertissement au niveau de l’application. Considérez les en-têtes comme des éléments de preuve, et non comme la preuve qu’un composant particulier a généré la réponse.
4. Vérifiez si le client a suivi des redirections ou signalé une réponse intermédiaire. Notez séparément la réponse finale et toute réponse précédente.

Si vous êtes un utilisateur d’API ou un visiteur

1. Si l’opération était censée créer quelque chose, vérifiez dans l’application que la nouvelle ressource existe avant de renvoyer la requête.
2. Si l’opération n’était pas censée créer quoi que ce soit, arrêtez les nouvelles tentatives et vérifiez la route, la méthode HTTP et la configuration du client.
3. Si une authentification est requise, connectez-vous via le parcours normal de l’application et ne recommencez l’opération que si cela est sûr et autorisé.
4. Fournissez au propriétaire du site l’URL et la méthode expurgées, l’horodatage, les en-têtes de réponse pertinents et l’identifiant de requête s’il est disponible. Ne partagez jamais d’identifiants, de cookies de session ni de secrets d’API.

Si vous gérez l’application ou le site

1. Reproduisez la requête dans un environnement sûr ou avec un compte de test autorisé. Capturez la méthode, l’URL, le statut, les en-têtes de réponse et un corps de réponse dont les données sensibles ont été masquées.
2. Identifiez le composant qui a produit la réponse : handler de l’application, serveur web, reverse proxy, CDN, WAF ou autre gateway. Comparez, lorsque cela est possible, les identifiants de requête ou les en-têtes de durée générés par le serveur avec les journaux.
3. Examinez les journaux correspondants de l’application et de l’infrastructure à l’horodatage relevé. Confirmez qu’une ressource a bien été créée et que l’opération n’a été validée qu’une seule fois, et non plusieurs.
4. Examinez les changements récents apportés aux routes, contrôleurs, traitements des requêtes, mécanismes d’authentification, règles de proxy et déploiements. Portez une attention particulière aux clients susceptibles de réessayer des requêtes de création non idempotentes.
5. Si 201 est incorrect pour l’endpoint, modifiez la règle applicative ou de routage la plus ciblée qui contrôle la réponse. Obtenez l’autorisation nécessaire et testez la modification avant de l’appliquer en production.
6. Testez à nouveau la même méthode, la même URL et le même payload, puis testez les routes associées de création, de lecture et de mise à jour afin de vérifier que leurs codes de statut et le comportement des ressources restent conformes aux attentes.

Prévention et vérification du correctif

• Définissez les méthodes HTTP et les codes de statut attendus pour chaque route publique, y compris le comportement lors de la création et des requêtes en double.
• Après les déploiements, testez les opérations de création, de lecture et de mise à jour avec des cas représentatifs authentifiés et non authentifiés.
• Faites gérer explicitement 201 par les clients et vérifiez la ressource renvoyée ou l’en-tête Location avant toute nouvelle tentative.
• Utilisez des identifiants de requête et conservez suffisamment longtemps les journaux de l’application, du proxy et de la gateway pour pouvoir retracer une réponse inattendue.
• Surveillez les taux de codes de statut par route et par méthode au lieu de considérer toutes les réponses 2xx comme interchangeables.
• Gardez les modifications de routage, d’authentification, de proxy et d’application sous contrôle de version et documentez les réponses 201 intentionnelles.

Questions fréquentes