Lekcja 1 / fundament API
HTTP bez paniki: request, response i pierwszy GET
Zaczynamy od sytuacji, którą naprawdę spotkasz w QA: ktoś mówi, że aplikacja „nie ładuje profilu”. Zanim zaczniesz klikać wszystko naraz, musisz zrozumieć jedną rozmowę: request wychodzi z klienta, response wraca z API.
Najpierw sytuacja
Użytkownik otwiera panel, a profil się nie pokazuje. Frontend może wyglądać na zepsuty, ale problem często siedzi krok niżej: aplikacja pyta API o dane profilu i dostaje odpowiedź, której nie umie obsłużyć. Postman pozwala odtworzyć tę rozmowę bez całej strony.
| Element | Co oznacza | Przykład |
|---|---|---|
| Client | Miejsce, które wysyła pytanie | przeglądarka, aplikacja mobilna, Postman |
| API | Adres, który przyjmuje request i oddaje dane | https://api.example.com/users/7 |
| Request | Pytanie wysłane do API | GET /users/7 |
| Response | Odpowiedź API | Status 200 i dane użytkownika |
Co robisz w Postmanie
W tej lekcji nie testujesz jeszcze wszystkiego. Robisz tylko jeden bezpieczny odczyt danych. Ustawiasz metodę GET, wpisujesz endpoint i wysyłasz request.
Request
GET https://jsonplaceholder.typicode.com/users/1
Nie ma body, bo tylko prosisz API o istniejące dane.
Oczekiwana odpowiedź
Status 200 OK i JSON z polem email, name oraz id.
GET https://jsonplaceholder.typicode.com/users/1
- Metoda — GET, czyli „daj mi dane”.
- Endpoint — adres zasobu, o który pytasz.
- Send — wysyła request.
- Status —
200 OKznaczy, że API zrozumiało pytanie. - Body — JSON, który wrócił w odpowiedzi.
Jak czytać wynik
Status 200 mówi: API zrozumiało request i oddało zasób. Nie znaczy jeszcze, że dane są
biznesowo poprawne. To tylko pierwszy filtr. Jeśli status jest 404, pytasz o zasób,
którego API nie znalazło. Jeśli 500, serwer ma problem po swojej stronie.
{
"id": 1,
"name": "Leanne Graham",
"email": "Sincere@april.biz"
}W zgłoszeniu „profil się nie ładuje” pierwszy fakt brzmi: czy endpoint profilu odpowiada i jakim statusem. Dopiero potem sprawdzasz szczegóły pól, autoryzację albo błąd po stronie frontendu.
Ćwiczenie
Wyślij request do https://jsonplaceholder.typicode.com/users/2. Zapisz w notatce:
jaki status wrócił, jakie jest pole email i czy odpowiedź wygląda jak obiekt jednego użytkownika,
czy lista wielu rekordów.
Mini-zadanie
Zmień końcówkę URL z /users/2 na /users/999 i sprawdź, co się zmieni.
Większa praktyka
Przygotuj krótką notatkę QA: „Co wysłałem?”, „Co wróciło?”, „Czy to potwierdza zgłoszenie?”. Nie diagnozuj jeszcze całej aplikacji. Na razie uczysz się zbierać pierwszy fakt.
Quiz
Co robi metoda GET?
Prosi API o odczyt danych. Nie powinna tworzyć ani modyfikować zasobu.
Czy status 200 oznacza, że aplikacja biznesowo działa poprawnie?
Nie. Oznacza, że request technicznie się udał. Dane nadal trzeba zinterpretować.
Po co QA używa Postmana, skoro jest frontend?
Żeby sprawdzić rozmowę z API bez mieszania jej z błędami widoku, kliknięć i stanu przeglądarki.
Co dalej?
Umiesz już odróżnić request od response i wysłać pierwszy GET. W następnej lekcji dodasz parametry, nagłówki i nauczysz się czytać JSON bardziej świadomie.