Swagger ist ein spezielles Werkzeug, das automatisch das RESTful API Dokument Ihrer Anwendung zusammenstellt.
Ihr Vorteil besteht darin, dass Sie nicht nur alle Endpunkte der Anwendung durchsehen, sondern sie auch sofort in Aktion testen können, indem Sie eine Anfrage senden und eine Antwort erhalten.
Für den Zugriff auf Swaggerzu gelangen, müssen Sie auf die Schaltfläche Preview in der veröffentlichten Anwendung drücken und auf den Namen des gewünschten Veröffentlichungsplans klicken (Deploy Plan).
In dem neu geöffneten Fenster wird eine Liste der verfügbaren Endpunkte und der mit diesen Endpunkten verbundenen Methoden angezeigt. Einige Anfragen sind nur für bestimmte Gruppen von autorisierten Benutzern verfügbar (siehe die Middleware der Auth module für jede spezifische Anfrage im Endpoints Abschnitt). A Bearer Token ist für Anfragen erforderlich, die nur für autorisierte Benutzer zulässig sind.
Sie können direkt auf den entsprechenden Endpunkt in Swagger zugreifen, um dieses Token zu erhalten (Auth Abschnitt, POST /auth Anfrage).
Drücken Sie Try it out und geben Sie Login und Passwort ein, um ein Token zu erhalten.
Die Anfrage wird gesendet an Execute. Wenn sie erfolgreich war, sehen Sie ein token Feld mit dem Bearer token Wert.
Die zweite Möglichkeit, ein autorisiertes Benutzer-Token zu erhalten, besteht darin, dass das Token im Anforderungskörper der bereitgestellten Anwendung gefunden werden kann.
- Drücken Sie F12 in Ihrem Web-Browser, um das Entwickler-Tool zu öffnen.
- Senden Sie eine beliebige Anfrage in Ihrer bereitgestellten Anwendung (z. B. zur Aktualisierung von Tabellen). Der Benutzer, der diese Anfrage sendet, muss für den Zugriff auf diesen Endpunkt autorisiert sein.
- Öffnen Sie Network und suchen Sie die entsprechende Anfrage.
- Gehen Sie zu Headers Registerkarte und finden Sie Request Headers Abschnitt. Bearer token wird präsentiert unter Authorization.
Geben Sie Bearer token an Swagger durch Drücken von Authorize drücken und den Wert einfügen, den Sie im vorherigen Schritt kopiert haben.
Für Testanfragen wählen Sie die gewünschte Gruppe und die Methode, die Sie ausführen möchten. Drücken Sie Try it out und geben Sie die Eingabeparameter der Anforderung ein. Klicken Sie auf Execute um die Antwort auszuführen.
Die am ehesten zu erwartende Antwort, wenn die Anfrage vom Server korrekt verarbeitet wurde, hat den Code 200 und zeigt, wie die Antwortstruktur aussehen sollte.
401 - die Anfrage wurde nicht erfolgreich abgeschlossen, da das erforderliche Autorisierungs-Token fehlt oder ungültig ist.
404 - die Anfrage wurde erfolgreich bearbeitet, aber die angeforderte Ressource wurde nicht gefunden.
422 - Es wurden falsche Parameter an den Eingang der Anfrage übergeben.
500 - ein Fehler bei der Verarbeitung der Anfrage durch den Server.
Benutzerdefinierten Fehler auslösen
Für benutzerdefinierte GPs und damit zusammenhängende Anfragen ist es möglich, benutzerdefinierte Fehlercodes mit Beschreibungen zu erstellen, indem Sie den Raise Error Block im GP-Editor zu erstellen. Ein Beispiel für einen solchen Prozess finden Sie unten:
Wenn in diesem Fall die Anfrage an den Endpunkt, der mit dem obigen BP verknüpft ist, fehlschlägt, gibt der Server einen 418-Fehler aus, der den Fehlertext enthält, wenn er die DB: Create Candidate block. Der Fehlercode kann in diesem Beispiel ein beliebiger sein, den der Benutzer angibt.
Hinweis: Der Antwortcode HTTP 418 I'm a teapot client error zeigt an, dass der Server sich weigert, Kaffee zu kochen, weil er permanent eine Teekanne ist. Eine kombinierte Kaffee-/Teekanne, die vorübergehend keinen Kaffee mehr hat, sollte stattdessen 503 zurückgeben. Dieser Fehler ist eine Anspielung auf Hyper Text Coffee Pot Control Protocol, die in Aprilscherzen von 1998 und 2014 definiert wurde.
