API w REST Assured 3. Pierwsze zapytanie do API

Po poprzedniej lekcji wprowadzającej w temat API i czym to w ogóle jest, w tej wyślemy pierwsze zapytanie do API. Pojawi się nowe narzędzie – Postman. Ułatwi nam ono pokazanie z czego składa się żądanie (zapytanie, request) oraz odpowiedź (response).

Pierwsze zapytanie do API: linki i materiały

Postman

Postman to narzędzie wspierające wytwarzanie API. My będziemy korzystali tylko z jego podstawowej funkcjonalności – klienta API. Narzędzie należy pobrać z www.getpostman.com, tam też znajdziemy dokumentację.

Postmana używać będziemy do rozmawiania z naszym lokalnym “fakeStorem”, a żeby być w stanie to robić wspierać nas będzie dokumentacja jego API. W tej lekcji szczególnie jeden fragment dokumentacji, ten dotyczący produktów.

Pierwsze zapytanie

Zaczniemy od pobrania listy produktów dostępnych w sklepie.  Na tym konkretnym przykładzie zobaczymy z czego składa się zapytanie do API:

• endpointa (punktu końcowego) – w naszym przypadku jest to adres, pod który wysyłamy request; jest to jakby wskazanie miejsca do którego możemy zapukać o jakiś zasób;
• nagłówków (które Postman magicznie będzie za nas dodawał);
• body, czyli ciała (pustego narazie) requestu (żądania).

Response (odpowiedź) podobnie do requesta, również zawiera nagłówek i ciało, ale poprzedzone kodem odpowiedzi.

Parametry

Zobaczycie też przykład wykorzystania parametrów dodawanych do requestu, które pozwolą wam modyfikować, czy filtrować oczekiwane odpowiedzi – można je dopisywać zarówno w pasku adresu, jak i w przeznaczonych do tego celu polach w Postmanie. Jak to dokładnie zrobić pokazuję na filmie.

Uwierzytelnianie

Wykorzystamy w naszych requestach podstawowe uwierzytelnianie (Basic Auth) oraz zobaczymy, że bez niego nie da się z naszego API wyciągnąć danych. To o czym warto wiedzieć, to że Basic Auth, to nic innego, jak dodanie do nagłówka requestu parametru: Authorization, o wartości “Basic xxxxxxx==” gdzie iksy to zakodowany przy użyciu algorytmu base64 ciąg znaków nazwa_użytkownika:hasło. Ponieważ base64 jest łatwo dekodowalny, nie powinniśmy przesyłać w ten sposób informacji bez użycia choćby SSL (w https).

Przy okazji uwierzytelniana przypomnę, że protokół http(s) jest synchroniczny – czyli zawsze operujemy na parach request-response. Sam REST jest także bezstanowy. Oznacza to, że każdy request powinien być całkowicie niezależny i możliwy do przetworzenia przez producenta API (my jesteśmy konsumentem!) bez oglądania się na jakiekolwiek wcześniejsze, czy późniejsze requesty. Po prostu nie istnieje coś takiego jak sesja w przypadku RESTowych API, uwierzytelnianie musi zachodzić w każdym żądaniu.

Ciało odpowiedzi

Na koniec dwa słowa o ciele odpowiedzi. W przypadku RESTowych webservice’ów będą one dostarczane zwykle w formacie XML, lub JSON. My od dziś, już przez cały kurs będziemy działali z JSONami, bo tak też jest zaprojektowane API z którego korzystamy. Na filmie zobaczysz też strukturę JSOna, którą pokrótce wyjaśniam. Zobaczysz co oznacza nawias kwadratowy, a co wąsaty (czyli klamrowy), a więc zobaczysz jak reprezentowane są listy i pojedyncze obiekty.