Swagger is een speciale tool die automatisch het RESTful API document van uw toepassing samenstelt.
Het voordeel hiervan is dat u niet alleen alle eindpunten van de applicatie kunt bekijken, maar ze ook meteen in actie kunt testen door een verzoek te sturen en een antwoord te ontvangen.
Om toegang te krijgen tot Swaggermoet u op Preview te drukken in de gepubliceerde toepassing en te klikken op de naam van het gewenste publicatieplan (Deploy Plan).
In het nieuw geopende venster wordt een lijst getoond van beschikbare eindpunten en methoden die bij deze eindpunten horen. Sommige verzoeken zijn alleen beschikbaar voor bepaalde groepen geautoriseerde gebruikers (zie de Middleware van de Auth module voor elk specifiek verzoek in de Endpoints sectie). A Bearer Token is vereist voor verzoeken die alleen zijn toegestaan voor geautoriseerde gebruikers.
U kunt het corresponderende eindpunt rechtstreeks in Swagger om dit token te krijgen (Auth sectie, POST /auth verzoek).
Druk op Try it out en voer login en wachtwoord in om een token te verkrijgen.
Verzoek zal worden verzonden op Execute. Als het succesvol is gegaan ziet u een token veld met de Bearer token waarde.
De tweede manier om een geautoriseerd gebruikerstoken te krijgen is dat het token te vinden is in de request body van de uitgezette applicatie.
- Druk op F12 in uw web-browser om de tool voor ontwikkelaars te openen.
- Stuur een verzoek in uw toepassing (bijvoorbeeld om tabellen bij te werken). De gebruiker die dit verzoek verstuurt, moet geautoriseerd zijn voor toegang tot dit eindpunt.
- Open Network en zoek het bijbehorende verzoek.
- Ga naar Headers tabblad en zoek Request Headers sectie. Bearer token zal worden gepresenteerd onder Authorization.
Geef Bearer token aan Swagger door op Authorize en de waarde te plakken die u in de vorige stap hebt gekopieerd.
Voor testverzoeken selecteert u de gewenste groep en de methode die u wilt uitvoeren. Druk op Try it out en vul de invoerparameters van het verzoek in. Klik op Execute om het antwoord uit te voeren.
Het meest verwachte antwoord, als het verzoek correct is verwerkt door de server, heeft de code 200 en laat zien hoe de antwoordstructuur eruit zou moeten zien.
401 - het verzoek is niet succesvol afgerond omdat het vereiste autorisatietoken ontbreekt of ongeldig is.
404 - het verzoek is met succes verwerkt, maar de gevraagde bron is niet gevonden.
422 - er zijn onjuiste parameters doorgegeven aan de invoer van het verzoek.
500 - een fout bij de verwerking van het verzoek door de server.
Aangepaste fout verhogen
Voor aangepaste BP's en gerelateerde verzoeken is het mogelijk om aangepaste foutcodes met beschrijvingen te maken met behulp van het Raise Error blok in de BP-editor. Hieronder staat een voorbeeld van een dergelijk proces:
In dit geval, als het verzoek naar het eindpunt geassocieerd met de BP hierboven mislukt, zal de server een 418 fout uitgeven met de fouttekst bij het uitvoeren van de . DB: Create Candidate block. De foutcode in dit voorbeeld kan elke zijn die de gebruiker opgeeft.
Opmerking: de HTTP 418 I'm a teapot client error response code geeft aan dat de server weigert koffie te zetten omdat hij, permanent, een theepot is. Een gecombineerde koffie/theepot die tijdelijk geen koffie meer heeft, moet in plaats daarvan 503 terugsturen. Deze fout is een verwijzing naar Hyper Text Coffee Pot Control Protocol die in aprilgrappen van 1998 en 2014 is gedefinieerd.
