Co to jest REST API ?
API (Aplikacyjny interfejs programistyczny) jest to zestaw reguł definiujących jak aplikacje lub części aplikacji powinny się ze sobą komunikować. W związku z tym, interfejs REST API to interfejs zgodny z zasadami opisanymi w REST (Representational State Transfer). Powinien charakteryzować się takimi cechami jak:
- Być zaimplementowanym w architekturze Klient-Serwer
- Posiadać jednolity interfejs, czyli 1 zadanie – 1 sposób realizacji
- Mieć System warstwowy – użytkownik ma dostęp bezpośrednio do aplikacji, ale nad nią może być osobny system uwierzytelniający np. SSO
- Być bezstanowy (ang. Stateless) – czyli możemy kilkukrotnie pytać o ten sam zasób i nie wpłynie to na zwracaną treść.
Aby lepiej zrozumieć czym jest Rest Api i jak je testować przyjrzymy się dokładniej poszczególnym zagadnieniom związanym z Rest Api.
Czym jest Testowanie?
Większość osób posiada wątpliwe wyobrażenie tego czym jest testowanie. Ludzie zazwyczaj postrzegają to jako tzw. ‘klikanie’ po aplikacji z zamiarem jej ‘popsucia’, tak by w ostateczności zaangażowany tester mógł wykazać się obnażając cudze błędy (programisty).
Gdy jednak przyjrzymy się dokładniej testowaniu to zdamy sobie sprawę, że testowanie jest zbiorem uporządkowanych czynności, których celem jest sprawdzenie w mierzalny sposób jakości danego oprogramowania. Najczęściej mówimy tutaj o tzw. weryfikacji oraz walidacji :
Czym jest zatem walidacja?
Otóż walidacja to sprawdzenie jak dobrze aplikacja realizuje potrzeby użytkowników oraz innych interesariuszy projektu informatycznego
Natomiast weryfikacja jest to sprawdzenie jak dobrze aplikacja spełnia postawione przed nią wymagania (najczęściej pisemne wymagania funkcjonalne i niefunkcjonalne ustalone z klientem)
To jak to jest z tym testowaniem?
Spróbujmy wytłumaczyć to sobie na przykładzie aplikacji Webowej. Wracając do tego mylnego pojęcia testowania, możemy założyć, że większość użytkowników Internetu postrzega aplikacje webowe w następującym schemacie :
Użytkownik wprowadza dane, klika przycisk szukaj i natychmiast (lub po lekkiej zadyszce) otrzymuje to, czego szuka (lub nie 😉). Z perspektywy takiego użytkownika wszystko dzieje się na ekranie jego komputera. Tutaj należy zaznaczyć, że tego typu testowanie stanowi tzw. testowanie całościowe lub z angielskiego (end-2-end). Jest to testowanie całego Systemu na który składa się oczywiście więcej elementów takich jak typu bazy danych, serwery, zestawy plików itp.
Jednak gdy spojrzymy szerzej na testowaną aplikację/system to najczęściej mamy do czynienia z następującym schematem:
Wówczas, to co rzeczywiście się dzieje, to:
- Użytkownik wprowadza dane, klika przycisk szukaj
- Przeglądarka przesyła odpowiednio zmodyfikowane żądanie do serwera
- Serwer przeszukuje bazę danych w poszukiwaniu lokalizacji pliku
- Sewer odsyła w odpowiedzi adres pliku (ogólnodostępny)
- Przeglądarka pokazuje trafienia oraz adresy plików (lub pliku)
- Użytkownik po kliknięciu na dany adres powoduje otworzenie danego zasobu, np. dokumentu pdf bezpośrednio w przeglądarce
W związku z powyższym w aplikacjach webowych najczęściej wyróżniamy 2 główne warstwy:
Warstwa graficzna, inaczej zwana ‘FRONT-END’, pokazuje dane użytkownikowi. Za jej pomocą użytkownik wchodzi w interakcję z całym systemem
ORAZ
Warstwa logiczna, inaczej zwana ‘BACK-END’, przetwarza żądania użytkownika i realizuje odpowiednie operacje, a następnie zwraca dane z powrotem do warstwy graficznej
Każdą z dwóch warstw możemy testować w izolacji, wówczas mówimy o testach integracyjnych:
Frontendu, np. przy użyciu bibliotek takich jak protractor, typeScript, Jasmine, które umożliwiają zasymulowanie (ang. Mock) odpowiedzi serwera
Backendu, np. przy użyciu programu takiego jak Postman czy dedykowanych bibliotek programistycznych
Zadaniem takich testów jest sprawdzenie czy obie strony odpowiednio się ze sobą integrują, tzn. wiedzą co jest od nich oczekiwane i jak należy komunikować się z drugą stroną.
Jak zatem testować REST API?
Testowanie REST API to nic innego jak wykonywanie testów integracyjnych poprzez odpytywanie serwera typu REST (żądaniami http) i sprawdzanie odpowiedzi przez niego przesyłanych.
Najczęstsze typy żądań HTTP
GET –żądanie informacji o zasobie, metoda nie powinna posiadać ciała (body), wielokrotne wykonanie nie wpływa na otrzymywaną odpowiedź
POST – żądanie utworzenia nowego zasobu, najczęściej przesyłane wraz z ciałem (body), w którym zawarte są parametry dla zasobu, wielokrotne wykonanie powinno skutkować powstaniem wielu nowych zasobów o tych samych parametrach
PUT – żądanie aktualizacji zasobu, w ciele metody przekazywane są wszystkie parametry zasobu wraz z informacją wskazującą na jego unikatowy numer, wielokrotne wykonanie takiego samego żądania nie wpłynie na sam zasób – będzie on aktualizowany na te same wartości za każdym razem i finalnie będzie miał taką samą postać
DELETE – żądanie usunięcia zasobu, najczęściej nie zawiera szczegółowych informacji (body).W celu poprawnego działania konieczne jest wskazanie identyfikatora zasobu, który ma zostać usunięty. Wielokrotne przesłanie takiego żądania nie wprowadzi zamieszania na serwerze, gdyż tylko 1 zasób o wskazanym identyfikatorze zostanie usunięty za pierwszym razem, a przy kolejnych próbach otrzymamy od serwera odpowiedź 404
Co na to serwer?
Wyróżniamy 5 grup odpowiedzi serwera, każda z nich zaczyna się od cyfry 1-5 i tak :
1XX (Informacja) potwierdzenie, że serwer zrozumiał nasze żądanie i jest gotowy do współpracy
2XX (Sukces) – żądanie zostało poprawnie przeprocesowane
3XX (Przekierowanie) – informacja dla klienta, że zasób znajduje się w innym miejscu i nastąpi przekierowanie
4XX (Błąd klienta) – żądanie nie jest przetworzone, ponieważ klient popełnił błąd, np. odwołał się do nieistniejącego zasobu (404)
5XX (Błąd serwera) – serwer nie jest w stanie zrealizować poprawnego żądania, np. wystąpienie wewnętrznych problemów serwera (500)
To tyle tytułem wstępu do serii artykułów na temat Rest Api, a już w kolejnym artykule przyjrzymy się bliżej przesyłaniu danych i analizie odpowiedzi serwera pod kątem poprawności implementacji.
Jeśli podobał Ci się artykuł zostaw komentarz.
Po więcej materiałów zapraszam Cię na kanał na youtubie @tujestbug i na Facebooka
Pozdrawiam !
Piotr.
0 komentarzy