429-, 414-, 499-, 405-fouten - foutmeldingen voor mislukte API-aanroepen

API-aanroepen mislukken soms vanwege extreem hoge verkeersbelasting. Dit is met name het geval wanneer meerdere aanroepen per seconde gelijktijdig en continu gedurende een langere periode worden verzonden. Laten we bijvoorbeeld, voor de wiskundige eenvoud, zeggen dat de API aanroepen verzendt met een snelheid van 10 records per seconde, en dat het antwoord aangeeft dat 5 aanroepen succesvol zijn geretourneerd, wat betekent dat 5 van die aanroepen zijn mislukt: mislukt bij het verzenden, mislukt bij het ontvangen, of mislukt bij het beantwoorden door de server, of D - al het bovenstaande.

*Opmerking: dit is een van de redenen waarom het wordt aanbevolen om niet meerdere aanroepen per seconde onafgebroken te verzenden, maar de aanroepen in plaats daarvan met één of twee seconden, of langer, te spreiden als een Best Practice. 

Een eindgebruiker kan een 429-foutmelding ontvangen van elke server, browser en applicatie. Afhankelijk van het gebruikte besturingssysteem / de gebruikte browser kan het bericht enigszins variëren:

1. 429-fout
2. HTTP 429
3. Fout 429 (Te veel verzoeken)

*Omdat ze allemaal '429' gemeen hebben, worden deze fouten meestal 429's genoemd.

429-fout en zijn vriend, de 414-fout 

Alle eindgebruikers moeten omgaan met gevallen van 429-fouten op basis van het protocol dat door hun organisatie is vastgesteld. 429-fouten worden niet opgelegd door de applicatie, maar zijn eerder het resultaat van het gedrag dat deze foutmelding heeft veroorzaakt. Het is belangrijk om op te merken dat dit geen fout van de applicatie of server is en daarom niet van buitenaf kan worden verholpen. 

In de eenvoudigste bewoordingen zijn 429-fouten signalen voor snelheidslimieten die de eindgebruiker moet aanpakken. Snelheidslimieten zijn niet universeel voor applicaties en liggen ook niet vast. Daarom kunnen ze alleen door de eindgebruiker worden aangepakt in relatie tot de instantie die de 429-fout heeft veroorzaakt. 

Nu we 429 begrijpen, laten we het hebben over 414-fouten 

Het is niet ongebruikelijk dat 429-fouten gepaard gaan met 414-fouten, die vaak worden weergegeven als: URL-verzoek te lang (URL & URI). Als je API-aanroepen worden verzonden met een snelheid waarbij ze niet tijdig genoeg kunnen worden beantwoord, zijn 414-fouten vaak het resultaat. De URL was te lang, of de combinatie van volume en snelheid resulteerde erin dat er niet snel genoeg kon worden gereageerd. 

499 Client gesloten verzoek 

HTTP-statuscode 499: Een niet-standaardstatuscode geïntroduceerd door Nginx die wordt geretourneerd wanneer de client de verbinding heeft gesloten voordat de server het verzoek kon beantwoorden, meestal veroorzaakt door een time-out aan de kant van de client (eindgebruiker). Treedt op wanneer een client de verbinding sluit terwijl Nginx het verzoek verwerkt. 

De 4XX-klasse van codes wordt vaak aangeduid als clientfoutcodes. De HTTP + 4 + XX geeft aan dat de client (eindgebruiker) iets verkeerd heeft gedaan. Er is specifiek sprake van een fout aan de clientzijde.  

Het geweldige ontwikkelingsteam van L2L helpt bij het diagnosticeren en oplossen van dit probleem. Het oplossen van 429-fouten is de eerste aanbeveling en zal u aanzienlijk sneller weer op weg helpen! 

Als u er meer over wilt lezen, is hier een artikel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429

405-foutmelding Methode niet toegestaan

De antwoordstatuscode 405 Methode niet toegestaan van het Hyper Text Transfer Protocol (HTTP) geeft aan dat de server de aanvraagmethode kent, maar dat de doelresource deze methode niet ondersteunt.