REST это архитектурный стиль, а не протокол и не стандарт. На собесе ждут, что вы объясните его просто и покажете, как это помогает тестировать.
Ресурсы и методы
Всё, с чем работает система, представлено ресурсами с адресами. Действие задаёт метод HTTP:
| Действие | Запрос |
|---|---|
| список | GET /users |
| один | GET /users/15 |
| создать | POST /users |
| заменить | PUT /users/15 |
| изменить часть | PATCH /users/15 |
| удалить | DELETE /users/15 |
| связанные | GET /users/15/orders |
Признаки плохого дизайна, о которых стоит писать в замечаниях: глаголы в адресе (/getUserOrders), POST для чтения, разные стили имён в одном API (userId рядом с user_id).
Ограничения REST
По Филдингу: клиент-сервер, отсутствие состояния между запросами, кешируемость, единообразный интерфейс, слоистость, необязательный код по запросу. JSON, /v1/ в адресе и конкретный набор методов это популярные соглашения, а не часть определения.
HATEOAS (ссылки на возможные действия прямо в ответе) встречается редко. Если он есть, его удобно тестировать: у отгруженного заказа не должно быть ссылки cancel.
Списки: фильтры, сортировка, пагинация
GET /products?category=books&sort=-price&limit=20&offset=40
Фильтры и сортировка в query-параметрах. Пагинация бывает двух видов:
- Offset:
limitиoffset(илиpage). Просто, но если между запросами страниц добавилась запись, последний элемент первой страницы повторится на второй. При удалении элемент пропадёт. - Курсорная:
?after=<id или дата последнего элемента>. Нет дублей и пропусков, но нельзя прыгнуть на 50-ю страницу.
Что проверять: limit=0, отрицательные и нечисловые значения, огромный limit, страницу за концом данных (пустой список, а не 500), сумму элементов всех страниц против total, стабильность сортировки при равных ключах. Параметр sort часто подставляют в SQL напрямую, туда стоит отправить инъекцию.
Версии и обратная совместимость
Ломающие изменения: удалить или переименовать поле, сменить тип, сделать поле запроса обязательным, поменять смысл кода. Неломающее обычно: добавить необязательное поле в ответ, при условии что клиенты игнорируют неизвестные поля. Ломающие изменения выпускают в новой версии (/v2/ или заголовок версии), а старую поддерживают, пока клиенты не обновятся. Особенно важно для мобильных приложений: старые версии живут у пользователей годами.
Ошибки
Хорошее API возвращает ошибки в одном формате. Есть стандарт Problem Details (RFC 9457, тип application/problem+json) с полями type, title, status, detail. Единый формат можно проверить схемой так же, как успешный ответ.
OpenAPI и Swagger
OpenAPI это стандарт описания REST-API в YAML или JSON: адреса, методы, параметры, тела, коды ответов, схемы данных. Swagger это инструменты вокруг: Swagger UI (интерактивная документация с кнопкой «Try it out»), Editor, Codegen. Раньше спецификация тоже называлась Swagger, поэтому слова путают.
Для тестировщика спецификация это требования:
- из неё видно обязательные поля, типы, ограничения и коды;
- её импортируют в Postman и получают готовую коллекцию;
- по её схемам валидируют ответы;
- расхождения кода и спеки сами по себе баги.
Частые ошибки
- Называть REST протоколом.
- Тестировать пагинацию одной страницей.
- Не проверять совместимость: старый клиент против нового API.
- Не считать отсутствие документации риском.
Что спросят на собесе
- Что такое REST API и чем он отличается от SOAP?
- Как в REST сделать CRUD?
- Что такое OpenAPI и как вы им пользовались?
- Как тестировать пагинацию и фильтры?
- Какие изменения API ломают клиентов?