Die automatisierte, Kein Code Datenstapel
Erfahren Sie, wie Astera Data Stack kann die Datenverwaltung Ihres Unternehmens vereinfachen und rationalisieren.
6 Häufig auftretende API-Fehler und wie man sie verhindert
APIs sind ein zunehmend wichtiger Bestandteil der Wirtschaft des 21. Jahrhunderts und unseres täglichen Lebens. Riesige Unternehmen wie Stripe und Amazon wurden auf hervorragenden Entwicklerplattformen aufgebaut. Sogar „analoge“ Tools wie Bürotelefonsysteme werden APIs ausgesetzt. Zunehmend fortschrittliche VoIP-Produkte integrieren Telefonsysteme für kleine Unternehmen mit Software wie Google Workspace. Dies eröffnet leistungsstarke neue Erfahrungen für Mitarbeiter und Kunden gleichermaßen. Aber APIs stehen nicht über Fehlern. Egal, ob Sie ein Hobby-Projektentwickler oder ein Millionen-Dollar sind SaaS-basiertes Produkt Benutzer werden feststellen, dass Störungen unvermeidlich sind.
Was ist ein API-Fehler/Fehler?
An API-Fehler tritt wenn ein Server die vom API-Anbieter angeforderte Ressource nicht finden kann. In solchen Fällen wird eine numerische Fehlermeldung zurückgegeben, um die Identifizierung des spezifischen Fehlers zu erleichtern. Häufige Ursachen für API-Fehler sind Probleme im Endpunkt, falsche Parameter oder Probleme mit dem API-Schlüssel während des Anforderungsaufrufs. Die Behebung dieser Fehler ist für die nahtlose Kommunikation zwischen Anwendungen und die Sicherstellung eines erfolgreichen Datenabrufs vom API-Anbieter von entscheidender Bedeutung.
6 häufige API-Fehler
Einige häufige API-Fehler sind:
- HTTP/HTTPS-Fehler.
- Nicht hilfreiche API-Fehler.
- Methodenverwechslungen.
- Fehlende Content-Type/Accept-Header.
- Autorisierungsfehler.
- Fehler bei der Datenformatierung.
1. HTTP/HTTPS-Fehler
Einer der häufigsten API-Fehler tritt auf, wenn die Protokolle http:// und https:// in URLs verwechselt werden.
Für Entwickler besteht das Problem darin, dass einige APIs nur das HTTP-Protokoll unterstützen, während andere HTTPS-kompatibel sind. Einige unterstützen unterschiedliche Standards an unterschiedlichen Endpunkten in demselben kundenorientierten Produkt.
Dies kann noch verwirrender werden, wenn Entwickler mehrere APIs aneinanderreihen. Wenn es sich um interne Entwickler handelt, die „DIY“-Lösungen für die asynchrone Geschäftskommunikation mit Remote-Teams erstellen. Entwickler müssen Zeit damit verbringen, den Endpunkt zu finden, der das Problem verursacht, und dann eine Problemumgehung erstellen, damit die beiden übrigen APIs miteinander kommunizieren.
Wenn Sie ein API-Anbieter, können Sie diesen Fehler verhindern, indem Sie bestimmte HTTPS-Strategien einsetzen. Beispielsweise könnten Sie Ihre API automatisch eingehende HTTP-Anfragen zu HTTPS-Anfragen umleiten lassen.
2. Nicht hilfreiche API-Fehlermeldungen
Für Ihre Benutzer kann die Qualität Ihrer Fehlermeldungen den Unterschied zwischen einem kurzen Schluckauf und einer Stunde, in der sie sich die Haare ausreißen, ausmachen, was hilfreich ist Reduzierung der Kundenabwanderung.
HTTP bietet über 70 HTTP-Statuscodes, aber Sie müssen mindestens nur die gängigsten Codes implementieren, mit denen Entwickler normalerweise arbeiten. Beispiele hierfür sind:
200 OK
Alles gut! Achten Sie nur darauf, diesen Statuscode nur dann anzugeben, wenn tatsächlich alles vorhanden ist is OK. Es ist bekannt, dass die Graph-API von Facebook immer dann einen 200-Code bereitstellt, wenn eine Ausgabe erfolgreich zurückgegeben wird, selbst wenn diese Ausgabe einen Fehlercode enthält.
400 Bad Request
Dies ist fast immer auf einen Tippfehler in der Eingabe Ihres Benutzers zurückzuführen. Aber das bedeutet nicht, dass Sie aus dem Schneider sind! Stellen Sie sicher, dass Ihre Fehlermeldung einige Einzelheiten über die fehlerhafte Eingabe enthält, damit der Benutzer sie schnell beheben kann.
401 Nicht autorisiert
Dieser Status bedeutet, dass die Eingabe in Ordnung ist, aber der Anfrage des Benutzers ein Autorisierungscode fehlt. Nicht zu verwechseln mit …
403 Verboten
Dies bedeutet, dass der Autorisierungscode als gültig erkannt wird, der Benutzer jedoch keine Berechtigung hat. Beispielsweise könnte ein Benutzer versuchen, auf etwas zuzugreifen, das nur den Administratoren zur Verfügung steht, was ein zunehmendes Sicherheitsproblem bei Remote-Mitarbeitern darstellt.
404 Not Found
Die Anforderung des Benutzers ist gültig, aber der Endpunkt oder die angeforderte Ressource ist nicht vorhanden. Dies kann daran liegen, dass die Datei inzwischen gelöscht wurde, aber stellen Sie sicher, dass dies nicht durch einen HTTP/HTTPS-Fehler verursacht wird.
429 Zu viele Anfragen
Dies tritt auf, wenn derselbe Benutzer versucht, die API zu oft kurz hintereinander aufzurufen. Nach einer Reihe hochkarätiger DDoS-Angriffe in den letzten zehn Jahren behalten Webdienste genau im Auge, wer wie oft auf ihren Server zugreift.
Diese Ratenbegrenzung ähnelt dem, was Sie auf jeder Domain oder anderen großen Websites finden würden. Webhosting-Anbieter wie Cloudflare übernehmen den DDoS-Schutz für Domains, die auf ihren Servern gehostet werden. Für APIs müssen diese Schutzmaßnahmen integriert sein.
5xx-API-Fehler
Statuscodes, die mit 5 beginnen, sind alle Serverfehler, möglicherweise auf Ihrer Seite. Wenn dies der Fall ist, stellen Sie sicher, dass Ihre Fehlermeldungen dem Benutzer Hilfe oder Beruhigung bieten. Dies können Kontaktinformationen oder eine Seite mit Live-Informationen zur Verfügbarkeit/Ausfallzeit sein.
API-Anbieter können schlechte Fehlermeldungen mit nur ein wenig Anpassung und Fehlerbehandlung vermeiden. Gehen Sie über den Fehlercode hinaus und verwenden Sie klare, prägnante Meldungen, die auf die Dokumentation verweisen.
Softwareanbieter sollten ein Zielverbraucherprofil der Entwickler erstellt haben, die ihre API verwenden werden. Fehlermeldungen können und sollten auf die Art der digitalen Aufgaben zugeschnitten werden, die sie zu erfüllen versuchen.
Schauen Sie sich diese Fehlermeldung von Twilio an, dessen API es Entwicklern ermöglicht, einen VoIP-Anruf zu tätigen.
“`
{
„Code“: 21211,
„message“: „Die Empfängernummer 5551234567 ist keine gültige Telefonnummer.“,
„mehr_info“: „https://www.twilio.com/docs/errors/21211“,
„Zustand“: 400
}
“`
Über den Standardstatus 400 hinaus gibt es oben einen benutzerdefinierten Fehlercode „21211“. Die Meldung bezieht sich sogar auf die spezifische virtuelle Telefonnummer, die das Problem verursacht. Es verweist den Benutzer auf die Seite in seiner Dokumentation, auf der er das Problem 21211 bespricht.
Schlechte Fehlermeldungen können ein großer Stolperstein für Entwickler sein, die versuchen, eine API in ihr produktorientiertes Unternehmen zu integrieren. Ein einfacher Integrationsprozess ist entscheidend für den Erfolg einer API. Eines der ersten Dinge, die viele Leute von Stripe hören, ist, wie einfach es ist, einfach ein paar Codezeilen einzufügen und Zahlungen in Gang zu bringen. Gute Fehlermeldungen sind also nicht nur wichtig für die Funktionalität, sie sind auch ein großartiges Marketing-Asset für Ihre API.
3. Methodenverwechslungen
APIs und ihre Benutzer können auf Fehler stoßen, wenn sie ihre Anfragemethoden verwechseln. Wenn der Benutzer eine POST-Anforderung sendet, die umgeleitet und als GET-Anforderung zurückgegeben wird, kann dies zu einem frustrierenden Fehler führen, der nicht seine Schuld ist.
Eine weitere Ursache für Methodenfehler ist eine unklare Dokumentation. Dies kann passieren, wenn ein Abschnitt Ihrer Dokumentation nicht erklärt, welche Methoden erforderlich sind, oder das falsche Verb verwendet. (Achten Sie darauf, die Wörter „get“ und GET synonym zu verwenden. Stellen Sie sicher, dass die Formatierung Ihrer Dokumente klar ist, und ersparen Sie sich eine E-Mail an den Kundensupport.)
4. Fehlende Content-Type/Accept-Header
Die meisten API-Aufrufe haben mindestens zwei Header-Daten: Content-Type und Accept. Diese Header helfen zwei Parteien – z. B. zwei APIs – auszuhandeln, welche Art von Daten übertragen und welche Arten als Gegenleistung akzeptiert werden. Wie jede Verhandlung können diese scheitern.
Einige APIs akzeptieren Anfragen ohne diese Header, wenn es keinen Grund gibt, so streng zu sein. Jede Codezeile führt mögliche Fehler in die Software ein, sodass Cloud-PBX-Anbieter häufig keine Header-Anforderung angeben, wenn dies nicht erforderlich ist. Aber in kommerziellen APIs mit Sicherheitsbedenken fragen Entwickler nach bestimmten Content-Type- und Accept-Headern. Auf diese Weise können sie streng kontrollieren, was in ihr System hineingelassen und was durchgelassen wird.
Content-Type teilt der API das Format des Datums mit, das Sie senden, und Accept teilt der API mit, was sie zurücksenden soll. APIs erfordern möglicherweise nur, dass Sie haben etwas In den Kopfzeilen akzeptieren einige bestimmte Typen und lehnen andere ab.
Diese Informationen sollten in der Dokumentation angegeben werden, wenn dies kein Sicherheitsrisiko darstellt, aber bestimmte Entwicklertools Benutzer ins Stolpern bringen können. Betrachten Sie curl, das automatisch den standardmäßigen Accept-Header in Anfragen einfügt. API-Anbieter können diese Tool-Eigenheiten antizipieren, indem sie die Anfrage ändern oder eine bestimmte Fehlermeldung senden.
5. Autorisierungsfehler
Dies ist ein häufiger API-Fehler und oft ein sehr einfacher. APIs, die das OAuth 2-Sicherheitsprotokoll verwenden, benötigen zusätzliche Header-Daten, um Anforderungen zu verarbeiten. Dies ist der „Authorization“-Header, der den privaten Schlüssel enthält, der für die API erforderlich ist, um die Anfrage zu verarbeiten.
Es ist ein häufiger Fehler, stattdessen einen „Authentifizierungs“-Header zu senden. Dies liegt daran, dass Entwickler und Dokumentation häufig synonym über Authentifizierung und Autorisierung sprechen. Aber selbst wenn der Header korrekt als „Autorisierung“ gekennzeichnet ist, können verwirrende Formatierungsfehler die Leute stolpern lassen.
Stellen Sie sicher, dass OAuth 2-API-Anforderungen so formatiert sind, mit dem „Bearer“-Flag vor dem privaten Schlüssel:
“`
Autorisierung: Träger {your_api_key_here}
“`
Benutzername/Passwort-Paare sollten wie „Benutzername:Passwort“ formatiert sein. Aber selbst wenn die API-Anforderung kein Passwort erfordert, müssen Benutzer möglicherweise einen Doppelpunkt am Ende anhängen. API-Anbieter könnten den Doppelpunkt selbst anhängen oder in der Dokumentation die genaue Formatierung klarstellen.
6. Datenformatierungsfehler
Auch wenn der Benutzer alles richtig macht, APIs kann immer noch Daten im falschen Format ausspucken. Wenn die API den Benutzern ihre Daten in HTML und nicht in JSON liefert, von dem sie dachten, dass sie gefragt hätten, könnte dies zu einem regelrechten Absturz führen. Schlimmer noch, ihre Softwareentwicklung akzeptiert die Daten möglicherweise gerne und verarbeitet sie auf eine Weise, die nicht erwartet wird.
Wenn der Entwickler versucht, Dienste zusammenzuführen, um die Konversionsrate für E-Commerce-Websites zu messen, sieht das Marketingteam den Code nicht. Sie könnten Tage damit verbringen, sich fehlerhafte Daten anzusehen, bevor jemand merkt, dass etwas nicht stimmt.
Wir haben Anforderungsmethoden erwähnt, die aufgrund einer Umleitung standardmäßig GET verwenden. Aber häufiger tritt dieser Fehler auf, wenn der Benutzer den Accept-Header nicht oder nicht richtig angegeben hat. Dies könnte Anbietern einen Grund geben, strenger zu sein, welche Inhaltstypen sie akzeptieren, auch wenn dies kein Sicherheitsrisiko darstellt.
API-Anbieter sollten auch die Arten von Antworten prüfen, die sie möglicherweise standardmäßig oder irrtümlich erhalten. Wenn Ihre API keinen Grund hat, HTML zu verarbeiten, sollten Sie diesen Inhaltstyp ablehnen. Dadurch werden Probleme vermieden, auf die Sie möglicherweise mit gängigen Tools stoßen. Wenn Nginx beispielsweise eine Zeitüberschreitung für eine Anfrage erhält, kann es Ihnen einen HTML-Fehler geben, von dem Ihre API keine Ahnung hat, wie es verarbeitet werden soll.
Fehler vermeiden erklärt
Um viele dieser häufigen Fehler zu vermeiden, müssen gründliche Tests durchgeführt werden. Es ist auch eine gute Idee, streng zu kontrollieren, welche Daten Ihre API akzeptiert, sobald sie in freier Wildbahn verfügbar sind. Darüber hinaus sollten API-Anbieter Wert auf exzellente API-Dokumentation und Fehlermeldungen legen.
Dies wird den Benutzern helfen, Probleme selbst herauszufinden, aber wenn es zu einem kommt Software für den Kundendienst, es wird Ihnen helfen, das Problem schneller zu lösen. Sobald Sie diesen Fehler identifiziert haben, ist es an der Zeit zu sehen, ob Sie Ihre Dokumente verbessern oder sogar das gesamte Problem abstrahieren können, damit es nicht wieder vorkommt.
