Abstrakt:
- Czym jest REST API?
- Krótko o protokole HTTP.
- Narzędnia do testowania API (subiektywny wybór najlepszych narzędzi według autora)
- Postman
- Newman i NPM
- RestAssured
- Visual Studio Code + REST Client
- RestSharp
Czym jest REST API?
To pytanie często pojawia się na rozmowach kwalifikacyjnych. Aby wyjaśnić to złożone pojęcie, najpierw wyjaśnię je oddzielnie.
Representation State Transfer jest architekturą i podejściem do komunikacji opisanymi przez Roya Fieldinga.
API natomiast to Application Programming Interface, czyli interfejs (ścisły zestaw reguł) po którym komunikujemy się pomiędzy aplikacjami w celu wymiany informacji.
REST API to połączenie API z architekturą REST.
Jakie więc jest to podejście konkretnie? Możemy opisać je w kilku punktach.
- Architektura klient – serwer
- Klient jest całkowicie odseparowany od serwera.
- Bezstanowość
- Architektura REST nie przetrzymuje informacji pomiędzy zapytaniami a serwer nie zapamiętuje żadnych informacji o kliencie.
- Warstwowość
- Klient nie wie czy jest podłączony do serwera czy do pośrednika, jeżeli mamy 5 warstw – to każda warstwa jest świadoma tylko warstwy z którą komunikuje się bezpośrednio (i nie wie o istnieniu innych warstw).
- Cacheable (keszowalność?)
- Klient przetrzymuje zasoby po swojej stronie (np. nie ma potrzeby ściągania przy każdym zapytaniu tego samego obrazu .jpg, więc klient zapisuje go na dysku i dopóki suma kontrolna pliku pozostaje niezmienna nie pobiera go ponownie)
- Jednolity interfejs
- dla wszystkich zasobów, serwer utrzymuje ten sam interfejs (na przykład serwer wysyła dane do klienta w formacie JSON lub XML niezależnie od wewnętrznej reprezentacji danych serwera)
- każdy zasób ma swoje unikalne URI (np. http://scvconsultants.com/users zwróci listę użytkowników, a http://scvconsultants.com/user/1 zwróci użytkownika numer 1)
- samoopisujące się wiadomości – każda wiadomość zawiera tyle informacji ile jest potrzebne do opisania jak ją przetworzyć
- HATEOAS czyli Hypermedia As The Engine of Application State – można powiedzieć, że to trzeci poziom REST API, który spełnia wszystkie założenia opisane w tym poście
Krótko o protokole HTTP.
Pełna definicja protokołu HTTP znajduje się tutaj (co polecam czytać kawałkami w trakcie przygotowania do testowania REST API).
REST API wykorzystuje głównie 5 zapytań z protokołu HTTP. Poniżej przykłady zapytań i prawidłowych odpowiedzi na nie.
HTTP request | CRUD | Pełna kolekcja (np. /users) | Pojedyńczy element (np. /user/{id}) |
---|---|---|---|
POST | Create | 201 (Created), 'Location' header z linkiem do /customers/{id} zawierającym nowe ID. | 404 (Not Found), 409 (Conflict) jeżeli zasób już istnieje |
GET | Read | 200 (OK), zwraca listę wszystkich użytkowników. Użyj paginacji, sortowania i filtrowania do nawigacji po dużych listach. | 200 (OK), pojedyńczy user. 404 (Not Found), jeżeli ID nie zostało znalezione lub jest nieprawidłowe |
PUT | Update/Replace | 405 (Method Not Allowed), o ile nie chcesz zaktualizować WSZYSTKICH zasobów w kolekcji. | 200 (OK) or 204 (No Content). 404 (Not Found), jeżeli ID nie zostało znalezione lub jest nieprawidłowe |
PATCH | Update/Modify | 405 (Method Not Allowed), jak wyżej | 200 (OK) or 204 (No Content). 404 (Not Found), jeżeli ID nie zostało znalezione lub jest nieprawidłowe |
DELETE | Delete | 405 (Method Not Allowed), o ile nie chcesz usunąć wszystkich danych z poziomu REST API. | 200 (OK). 404 (Not Found), jeżeli ID nie zostało znalezione lub jest nieprawidłowe |
Narzędzia do testowania API
Postman
Narzędzie (samodzielna aplikacja, która historycznie wyewoluowała z addona do przeglądarki Chrome) z ładnym i intuicyjnym GUI do testowania zapytań.
Dlaczego warto z niego korzystać:
- Jest darmowy (wersja płatna ma kilka usprawnień, ale do zwykłego testowania wystarczy nam bezpłatna)
- Szybki i intuicyjny próg wejścia (zapytania tworzymy w intuicyjnych okienkach i wciskamy „Send”)
- Możliwość pisania testów w JavaScript do każdego zapytania
- Możliwość tworzenia kolekcji (łańcuchów wielu zapytań) z których każde ma swoje testy i potrafią przekazywać dane między sobą
- Możliwość mockowania odpowiedzi z API
- Obsługa wielu środowisk
- Wbudowany runner testów i automatyczne raportowanie
- Istnieją wersje dla wszystkich popularnych systemów operacyjnych.
- Wspiera import dokumentacji Swaggera, która sama tworzy odpowiednie zapytania do API. Wystarczy użyć funkcji Import From Link jak na screenie poniżej
Minusy stosowania Postmana:
- Mała elastyczność (brak możliwości wysyłania zapytania GET z body ;))
- Konieczność pisania testów w JavaScript (brak obsługi innych języków)
- Brak podpowiedzi składni w edytorze testów.
- Płatne, dość kosztowne funkcje jeżeli chcemy pracować w zespole rozproszonym
Newman + NPM
Narzędzie CLI do uruchamiania testów i zapytań stworzonych w Postmanie. Wymaga NPMa, który pozwoli uruchomić testy api w konsoli na dowolnym systemie operacyjnym (i generować jakże potrzebne naszym menadżerom kolorowe (zielono–czerwone) raporty).
.
RestAssured
Biblioteka w Javie do pisania testów REST API. Jeżeli projekt pisany jest w Javie i nasze środowisko CI jest już skonfigurowane – może być dobrym pomysłem wykorzystać Javę do automatyzacji testów (unikniemy narzutu instalacji NPMa, dodatkowej konfiguracji Jenkinsa, TeamCity czy VSTS).
Dlaczego wybrałem akurat tą?
- Wsparcie community
- Open source
- Nieduży próg wejścia
- Bardzo dobrą dokumentacja.
- Testy pisane w stylu Gherkina (Given / When / Then) i duża czytelność kodu
Chętnym na zapoznanie się z tym polecam wpis na blogu Sławka z przykładami kodu w Javie: tutaj i tutaj
Visual Studio Code + REST Client
Addon do VS Code, do uruchamiania zapytań z poziomu IDE.
Wystarczy stworzyć plik .http, zapisać i możemy wysyłać jednym kliknięciem dowolne zapytania które tworzymy w pliku
Plusy:
- Zerowy próg wejścia
- Elastyczność (chcemy wysłać GET z body – proszę bardzo)
- Darmowy addon do VS Studio, który zaczyna być najpopularniejszym edytorem kodu wśród programistów.
Minusy:
- Trudno nazwać to testami automatycznymi, więc polecam to raczej do doraźnego stosowania w pojedyńczych przypadkach
RestSharp
Prosty klient REST API napisany w C#.
Plusy:
- Open source
- Wsparcie community
- Prosta integracja ze SpecFlow i xUnit / nUnit
- Dobra dokumentacja.
Minusy:
- Jest to biblioteka do tworzenia REST Api a nie jego testowania, więc musimy sami sobie dopisać wiele rzeczy
Ponownie powtórzę jak mantrę: jeżeli nasz projekt pisany jest w języku X to nasze testy automatyczne powinny być pisane również w języku X. Chyba, że potrafimy uzasadnić koszty związane z różnymi językami naszym menadżerom.
Słowo i prośba na koniec
Jeżeli dotarłeś tutaj i chciałbyś się ze mną podzielić jakimś narzędziem, którego używałeś (i nie jest to SOAP UI, którego celowo pominąłem) to z miłą chęcią przeczytam Twój komentarz.
Alternatywa dla Postmana jest chyba Insomnia – kolega uzywal w robocie wlasnie ze wzgledu na mozliwosci wysylania GETa z body.
Jest tez jakis taki frameworka javascriptowy, Cypress, do testow end2end ale API tez mozna testowac: https://github.com/cypress-io/cypress-example-api-testing