З чого складається запит і відповідь
Запит = метод + URL + заголовки + тіло. Відповідь = статус-код + заголовки + тіло.
POST https://api.bank.test/v1/accounts/42/transfers?dryRun=false
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Idempotency-Key: 7f3c-...
{ "toAccount": "UA21...", "amount": 150.00, "currency": "UAH" }
Тут видно всі частини: метод POST, base URL з версією API, шлях до ресурсу з path-параметром 42, query-параметр dryRun, три заголовки і JSON-тіло. Кожна з цих частин — окреме джерело тест-кейсів, тому при аналізі нового ендпоінта я розбираю запит саме так, по шматках.
Path vs query. Path вказує на конкретний ресурс (/users/42), query фільтрує чи налаштовує видачу (/users?status=active&page=2). Правило просте: якщо без параметра ресурс втрачає сенс — це path, якщо це опція видачі — query.
На співбесіді: Запит складається з методу, URL, заголовків і тіла, відповідь — зі статус-коду, заголовків і тіла. Path-параметр ідентифікує ресурс, query-параметр фільтрує, сортує чи пагінує видачу.
Що перевіряти в кожній частині
Ця таблиця — готовий план негативних і позитивних кейсів для будь-якого ендпоінта.
| Частина | Приклад | Що перевіряти |
|---|
| Base URL | https://api.bank.test/v1 | Виносити в змінну {{baseUrl}} |
| Path | /accounts/42/transfers | Чужий або неіснуючий id дає 403 або 404 |
| Path param | 42 | Невалідний тип (abc) дає 400 |
| Query param | ?dryRun=false | Фільтри, пагінація, сортування |
| Headers | Authorization, Content-Type, Accept | Без токена 401; хибний Content-Type 415 |
| Body | JSON з полями | Обов'язкові поля, типи, межі |
| Status | 201 Created | Код відповідає документації |
| Response headers | Content-Type, Location | Тип вмісту, кеш, CORS |
| Response body | { "id": "tr_91", "status": "pending" } | Структура, типи, значення, жодних зайвих чутливих полів |
| Time | 180 ms | У межах SLA |
Зверніть увагу на Location у відповіді на створення: там часто лежить URL нового ресурсу, і його зручно використати для наступного GET. А перевірка «жодних зайвих чутливих полів» — це не формальність: якщо у відповіді є хеш пароля чи повний номер картки, це вже дефект безпеки, навіть коли все інше правильне.
На співбесіді: Я проходжу запит по частинах: URL і path-параметри, query, заголовки, тіло, а у відповіді — статус, заголовки, тіло й час. Для кожної частини є свої негативні кейси, наприклад невалідний тип id дає 400, а хибний Content-Type — 415.