Fehlerbehandlung und Testen von REST-APIs

Name: Fehlerbehandlung und Testen von REST-APIs
Author: Josh Guardino

Sielernen, wie Sie mit REST-API-Fehlern umgehen und automatisierte Tests erstellen und ausführen.

Preview the first lesson free — get full access to all 3 lessons.

Kurs: On-Demand

Hallo, mein Name ist Josh Gardino, und in diesen Lektionen zeige ich Ihnen, wie Sie mit Fehlern umgehen und testen Sie REST-APIs. Denken Sie daran, dass HTTP-Antwortstatuscodes unterteilt sind in mehrere Gruppen einteilen. Statuscodes im Bereich 400 und 500 gelten als Fehler. Allerdings ist der entscheidende Unterschied ist, dass Statuscodes, die mit einer Vier beginnen, Clientfehler sind und Statuscodes, die mit einer Fünf beginnen, sind Serverfehler. Clientfehler wären Fehler im Zusammenhang mit der Anfrage selbst. Die Anfrage enthielt möglicherweise falsch formatiertes JSON. Der Zugriff auf den angeforderten Pfad war verboten, Die angeforderte Ressource konnte nicht gefunden werden und mehr. Wenn Clientfehler auftreten, Es ist wichtig, dass der Server antwortet mit dem korrekten Statuscode der 400er-Serie. Allerdings unter Beibehaltung aller Details Informationen zum Clientfehler sind normalerweise nicht erforderlich auf der Serverseite. Der Kunde sollte in der Lage sein, das Problem zu lösen und senden Sie eine neue Anfrage. Von größerer Bedeutung auf der Serverseite sind die Server-Fehlercodes, und das sind diejenigen, die mit fünf beginnen. Obwohl es zahlreiche Antwortcodes für Serverfehler gibt, Das mit Abstand wichtigste und relevanteste ist 500. 500 weist auf einen internen Serverfehler hin für einen unerwarteten Zustand auf der Serverseite, was bedeutet, dass ein Fehler aufgetreten ist. Der Statuscode 500 ist vorgesehen um eine allgemeine Sammelantwort zu sein. Es ist jedoch normalerweise der einzige Typ des serverseitigen Fehlercodes den der serverseitige REST-API-Code verarbeiten muss. Es können andere serverseitige Fehlercodes auftreten von einem Client, z. B. 503, angegeben dass der Server nicht bereit ist. Typischerweise werden jedoch solche Antworten gesendet durch ein API-Gateway und nicht durch die Anwendung selbst. Lass uns einen Blick darauf werfen bei der Abteilung für Kraftfahrzeuge API in Postman. Hier ist der v1/drivers GET-Endpunkt und wenn ich auf Senden klicke, wird der Statuscode 200 zurückgegeben und eine Liste aller Treiber aus der Datenbank. Schauen wir uns nun an, wie das im Quellcode aussieht. Hier ist der Handler für die GET-Methode. Es führt eine Auswahlabfrage durch auf der Datenbank und gibt alle Daten zurück. Dies funktioniert einwandfrei, wenn keine Fehler auftreten. Lassen Sie uns jedoch das Auftreten eines Fehlers erzwingen. In Zeile 12 werde ich einen ungültigen Code eingeben. Starten wir den Server neu und kehren zu Postman zurück. Ich werde auf "Senden" klicken und wie Sie sehen können, Ich habe weder einen Statuscode noch irgendeine Antwort erhalten. Postman zeigt einen ECONNRESET-Fehler an. Das bedeutet, dass der Server nicht geantwortet hat mit allem, was Postman verarbeiten konnte. Kehren wir dorthin zurück, wo der Server läuft. Mein lokaler Server hat den xyz-Fehler genau erkannt und zeigte die vollständigen Details im Konsolenfenster an. Diese Details werden als Stack-Trace bezeichnet und sie sind für Debugging-Zwecke sehr wichtig. Die erste Zeile in der Fehlerausgabe sagt es mir dass dies ein Referenzfehler war weil der Server nicht verstanden hat, was xyz ist, Der Fehler wird also ordnungsgemäß erfasst Aber der Kunde hat keine Ahnung, was passiert ist. Der Server könnte ausgefallen sein, es könnte ein Netzwerkproblem vorliegen Auf der Clientseite könnte ein serverseitiger Fehler vorliegen aber der Kunde hat keine Möglichkeit zu wissen, was passiert ist und das liegt daran, dass dieser Code keinen Typ ausführt der Fehlerbehandlung. Wenn der Fehler auftritt, Der Server erkennt, dass etwas schief gelaufen ist es wird jedoch keine Antwort gesendet, da für die GET-Methode Der einzige Antworttyp, der gesendet wird, ist 200. Fügen wir nun etwas Fehlerbehandlung hinzu zur Node.js Express-Anwendung mit Try- und Catch-Anweisungen. Jetzt wird der Fehler behandelt und alle Fehler werden in Zeile 16 abgefangen. In Zeile 17 sende ich einen Status von 500 an den Kunden. Gehen wir zurück zu Postman und probieren es aus. Wenn ich nun die Anfrage sende, Ich erhalte eine Antwort mit dem Statuscode 500 Zeigt einen internen Serverfehler an. Der Kunde weiß nicht genau, was passiert ist auf der Serverseite, aber es enthält viel mehr Informationen als bei der vorherigen Anfrage. Es ist natürlich möglich, die vollständigen Details zu senden des Fehlers zurück an den Kunden, zusammen mit dem 500 internen Serverfehlerstatuscode aber das ist sicherlich problematisch. Am wichtigsten ist, dass dadurch interne Details offengelegt werden über die API und dies stellt ein potenziell ernstes Sicherheitsproblem dar aber auch diese Informationen sind für den Kunden nicht hilfreich, Es gibt also keinen Grund, es zu senden aber das bedeutet nicht, dass der Server muss eine generische Serverantwortnachricht zurückgeben. Kommen wir zurück zum Code und fügen Sie eine freundliche Fehlermeldung hinzu. Wenn wir nun diese Anfrage senden, erhalten wir immer noch eine 500 aber mit einer angepassten Fehlermeldung. Ein weiterer Grund, eine benutzerdefinierte 500-Statuscode-Nachricht zu verwenden ist es, dem Kunden ein Tracking zur Verfügung zu stellen oder Korrelations-ID, die die Mitarbeiter auf Kundenseite haben der API könnte mit dem serverseitigen Personal geteilt werden um eine detaillierte Fehlerbehebung durchzuführen. Danke fürs zuschauen. Seien Sie gespannt auf die nächste Lektion, die ich Ihnen zeigen werde wie man automatisierte Tests für GET-Anfragen in der REST-API verwendet.

Anfänger Anbieter : Josh Guardino 3 Lektionen · 17m auf Arabisch, Deutsch, Englisch, Spanisch, Französisch, Portugiesisch, Chinese

Kursbeschreibung

APIs sind von Natur aus verteilte Softwareanwendungen, die aus entfernten Clients und Servern bestehen, die über ein Netzwerk verbunden sind. Während Remoting die Welt, wie wir sie kennen, verändert hat, bringt es auch eine enorme Liste potenzieller Fallstricke und Probleme mit sich. Server und Netzwerke stürzen ab. Computer können sich auf unerwartete Weise verhalten. Clients ändern sich und können Anfragen und Antworten nicht verarbeiten. All dies führt zu einer konstanten Wahrheit: Der einzige bekannte Faktor ist das Unbekannte.

Um mit dem Unerwarteten umgehen zu können, ist es für RESTful-Clients und -Server wichtig, diese Bedingungen anständig zu behandeln. In diesen Lektionen lernen Sie, wie Fehler auf beiden Seiten auftreten und wie die Kombination aus Fehlerdetails, Statuscodes und Meldungen optimal verarbeitet werden kann.

Die beste Verteidigung gegen Instabilität und Inkonsistenz von Software ist, sie konsequent und regelmäßig zu testen. Wir zeigen Ihnen, wie Sie mit TestProject, einem kostenlosen webbasierten Tool, REST-API-Tests skripten und automatisieren können, um Fehlerzustände zu erkennen und zu identifizieren und nützliche Informationen für die Fehlersuche und Leistungsoptimierung bereitzustellen.

Was Sie lernen werden

Identifizieren Sie die häufigsten Arten von REST-API-Fehlern und ihre entsprechenden Statuscodes
Erkennen Sie, wie Fehler sowohl auf der Client- als auch auf der Server-Seite einer API auftreten
Verarbeiten Sie Fehlerdetails, Statuscodes und Meldungen optimal, um mit dem Unerwarteten anmutig umzugehen
Konfigurieren und führen Sie TestProject aus, um REST-API-Tests für GET-Anfragen zu schreiben und zu automatisieren
Konfigurieren und führen Sie TestProject für POST-, PUT-, PATCH- und andere Schreibvorgänge aus
Verwenden Sie automatisierte REST-API-Tests, um Fehlerbedingungen zu entdecken und Informationen zum Debuggen und zur Leistungsoptimierung bereitzustellen

Wichtige Erkenntnisse

APIs sind verteilte Anwendungen von Remote-Clients und Servern, die sich über ein Netzwerk verbinden, was viele potenzielle Probleme einführt, wie z. B. Server und Netzwerke, die ausfallen, oder Clients, die Anfragen und Antworten nicht verarbeiten können.
RESTful-Clients und Server sollten mit unerwarteten Bedingungen anmutig umgehen, indem sie Fehlerdetails, Statuscodes und Meldungen kombinieren und sie optimal verarbeiten.
Konsistentes und regelmäßiges Testen ist die beste Verteidigung gegen Softwareinstabilität und Inkonsistenz.
TestProject ist ein kostenloses webbasiertes Tool, das zum Schreiben und Automatisieren von REST-API-Tests verwendet wird, um Fehlerbedingungen zu identifizieren und Debuggen und Leistungsoptimierung zu unterstützen.
Der Kurs behandelt die Handhabung von GET-Anfragen und Schreibvorgängen wie POST, PUT und PATCH.

Häufig gestellte Fragen

Was behandelt dieser Kurs?

Er behandelt, wie Fehler auf beiden Seiten (Client und Server) von REST-APIs auftreten, wie Fehlerdetails, Statuscodes und Meldungen optimal verarbeitet werden können, und wie TestProject verwendet wird, um REST-API-Tests zu schreiben und zu automatisieren, um Fehlerbedingungen zu entdecken und Debuggen und Leistungsoptimierung zu unterstützen.

Welches Test-Tool wird in diesem Kurs verwendet?

Der Kurs verwendet TestProject, ein kostenloses webbasiertes Tool, um REST-API-Tests zu schreiben und zu automatisieren.

Welche Arten von API-Anfragen lehrt der Kurs zu testen?

Er unterrichtet die Konfiguration und Ausführung von TestProject für GET-Anfragen sowie für POST-, PUT-, PATCH- und andere Schreibvorgänge.

Welche Fähigkeiten hilft dieser Kurs aufzubauen?

Er behandelt Fähigkeiten einschließlich API-Design, API-Management, API-Tests, REST-API-Entwicklung, REST-Client und RESTful-API.

Welche Lektionen sind in diesem Kurs enthalten?

Der Kurs umfasst drei Lektionen: REST-API-Fehlerbehandlung und -Tests; HTTP-GET-Methoden; und POST-, PUT- und PATCH-Anfragen.