Erreurs 429, 414, 499, 405 - messages d’erreur d’échec d’appel d’API

Les appels API échouent parfois en raison de charges de trafic extrêmement élevées. Cela est particulièrement le cas lorsque plusieurs appels par seconde sont envoyés simultanément et continuellement sur une période prolongée. Par exemple, et pour simplifier les calculs, disons que l’API envoie des appels à un rythme de 10 enregistrements par seconde, et que la réponse retournée indique que 5 appels ont été retournés avec succès, ce qui signifie que 5 de ces appels ont échoué : échec de l’envoi, de la réception ou de la réponse du serveur, ou D - tout ce qui précède.

*Remarque : c’est l’une des raisons pour lesquelles il est recommandé de ne pas envoyer plusieurs appels par seconde sans interruption, mais plutôt d’espacer les appels d’une ou deux secondes, voire davantage, comme meilleure pratique. 

Un utilisateur final peut recevoir un message d’erreur 429 de la part de n’importe quel serveur, navigateur ou application. Selon le système d’exploitation / navigateur utilisé, le message peut varier légèrement :

1. erreur 429
2. HTTP 429
3. Erreur 429 (Trop de requêtes)

*Comme ils ont tous « 429 » en commun, ces erreurs sont le plus souvent appelées des 429.

Erreur 429 et son ami, l’erreur 414 

Tous les utilisateurs finaux doivent gérer les cas d’erreurs 429 selon le protocole établi par leur organisation. Les erreurs 429 ne sont pas imposées par l’application, mais résultent plutôt du comportement qui a déclenché ce message d’erreur. Il est important de noter qu’il ne s’agit pas d’une défaillance de l’application ou du serveur et qu’elle ne peut donc pas être corrigée de l’extérieur. 

En termes simples, les erreurs 429 sont des signaux de limitation de débit auxquels l’utilisateur final doit répondre. Les limites de débit ne sont pas universelles entre les applications et ne sont pas non plus immuables, c’est pourquoi elles ne peuvent être traitées que par l’utilisateur final en fonction du cas qui a déclenché l’erreur 429. 

Maintenant que nous comprenons l’erreur 429, parlons des erreurs 414 

Il n’est pas rare que les erreurs 429 soient accompagnées d’erreurs 414, qui sont souvent présentées comme suit : Requête URL trop longue (URL & URI). Si vos appels API sont envoyés à un rythme tel qu’ils ne peuvent pas recevoir de réponse dans un délai suffisamment court, des erreurs 414 en résultent souvent. L’URL était trop longue, ou la combinaison du volume et de la vitesse a empêché une réponse suffisamment rapide. 

499 Requête fermée par le client 

Code d’état HTTP 499 : Un code d’état non standard introduit par Nginx qui est renvoyé lorsque le client a fermé la connexion avant que le serveur ne puisse répondre à la demande, le plus souvent en raison d’un délai d’attente côté client (utilisateur final). Se produit lorsqu’un client ferme la connexion pendant que Nginx traite la demande. 

La classe de codes 4XX est souvent appelée codes d’erreur client. HTTP + 4 + XX indique que le client (utilisateur final) a fait quelque chose d’incorrect. Plus précisément, il s’agit d’une erreur côté client.  

La formidable équipe de développement de L2L vous aidera à diagnostiquer et à résoudre ce problème. La correction des erreurs 429 sera la première recommandation et vous permettra de vous remettre sur pied beaucoup plus rapidement ! 

Si vous souhaitez en savoir plus à ce sujet, voici un article : https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429

Erreur 405 Méthode non autorisée

Le code d’état de réponse 405 Méthode non autorisée du protocole de transfert hypertexte (HTTP) indique que le serveur connaît la méthode de la demande, mais que la ressource cible ne prend pas en charge cette méthode.