Swagger to specjalne narzędzie, które automatycznie składa RESTful API dokument swojej aplikacji.
Jego zaleta polega na tym, że pozwala nie tylko przejrzeć wszystkie punkty końcowe aplikacji, ale także od razu przetestować je w działaniu, wysyłając żądanie i otrzymując odpowiedź.
Aby uzyskać dostęp Swaggernależy nacisnąć na Preview w opublikowanej aplikacji i kliknąć na nazwę żądanego planu wydawniczego (Deploy Plan).
W nowo otwartym oknie zostanie wyświetlona lista dostępnych punktów końcowych i metod związanych z tymi punktami. Niektóre żądania są dostępne tylko dla określonych grup autoryzowanych użytkowników (zob. Middleware z Auth module dla każdego konkretnego żądania w sekcji Endpoints sekcji). A Bearer Token jest wymagany dla żądań, które są dozwolone tylko dla autoryzowanych użytkowników.
Możesz uzyskać dostęp do odpowiedniego punktu końcowego bezpośrednio w Swagger aby uzyskać ten token (Auth sekcja, POST /auth żądanie).
Naciśnij Try it out i wpisz login i hasło, aby uzyskać token.
Wniosek zostanie wysłany na Execute. Jeśli przebiegło pomyślnie, zobaczysz token pole z Bearer token wartość.
Drugi sposób na uzyskanie tokena autoryzowanego użytkownika polega na tym, że token można znaleźć w ciele żądania wdrożonej aplikacji.
- Naciśnij F12 w przeglądarce internetowej, aby otworzyć narzędzie dewelopera.
- Wyślij dowolne żądanie w swojej wdrożonej aplikacji (na przykład, aby zaktualizować tabele). Użytkownik, który wysyła to żądanie musi być upoważniony do dostępu do tego punktu końcowego.
- Otwórz Network zakładkę i znajdź odpowiadające jej żądanie.
- Przejdź do Headers zakładkę i znajdź Request Headers sekcja. Bearer token zostanie przedstawiona pod Authorization.
Podaj Bearer token do Swagger naciskając Authorize i wklejając wartość, którą skopiowałeś w poprzednim kroku.
Dla zapytań testowych wybierz żądaną grupę i metodę, którą chcesz wykonać. Naciśnij Try it out i wypełnij parametry wejściowe żądania. Kliknij Execute aby wykonać odpowiedź.
Najbardziej oczekiwana odpowiedź, jeśli żądanie jest poprawnie przetwarzane przez serwer, ma kod 200 i pokazuje, jak powinna wyglądać struktura odpowiedzi.
401 - żądanie nie zostało zakończone pomyślnie, ponieważ brakuje wymaganego tokena autoryzacji lub jest on nieważny.
404 - żądanie zostało przetworzone pomyślnie, ale żądany zasób nie został znaleziony.
422 - do wejścia żądania zostały przekazane nieprawidłowe parametry.
500 - błąd przetwarzania żądania przez serwer.
Wywołaj niestandardowy błąd
W przypadku niestandardowych BP i powiązanych żądań można utworzyć niestandardowe kody błędów z opisami za pomocą Raise Error w edytorze BP. Przykład takiego procesu znajduje się poniżej:
W tym przypadku, jeśli żądanie do punktu końcowego związanego z powyższym BP nie powiedzie się, serwer wystawi błąd 418 zawierający tekst błędu podczas wykonywania polecenia. DB: Create Candidate block. Kod błędu w tym przykładzie może być dowolny, określony przez użytkownika.
Uwaga: kod odpowiedzi błędu HTTP 418 I'm a teapot client wskazuje, że serwer odmawia zaparzenia kawy, ponieważ jest, na stałe, czajnikiem. Połączony dzbanek do kawy/herbaty, w którym chwilowo zabrakło kawy, powinien zamiast tego zwrócić 503. Ten błąd jest odniesieniem do Hyper Text Coffee Pot Control Protocol zdefiniowanego w żartach prima aprilisowych w 1998 i 2014 roku.
