Какие принципы построения REST API существуют?

Что проверяют

Умеете ли вы превратить принципы REST в проверки. Тестировщику мало перечислить методы: нужно понимать, какое поведение API из них следует и где его чаще всего ломают. Следом обычно просят накидать тест-кейсы на конкретный эндпоинт, например POST /orders.

Как отвечать

Назовите принципы и к каждому сразу привяжите проверку:

• ресурсы и URI: /users для коллекции, /users/42 для элемента. Несуществующий id даёт 404, id в неверном формате даёт 400 или 422, но не 500;
• семантика методов: GET ничего не меняет, PUT заменяет ресурс целиком, PATCH меняет часть полей. Неподдерживаемый метод должен вернуть 405, неверный Content-Type тела даёт 415;
• идемпотентность: повторите PUT или DELETE и убедитесь, что состояние на сервере то же, что после первого вызова. Повтор POST создаёт дубль, если API не принимает ключ идемпотентности, и для заказов это готовый баг;
• отсутствие состояния: каждый запрос самодостаточен. Без токена приходит 401, с токеном без прав 403, и эти коды не путаются;
• кеширование: заголовки Cache-Control и ETag, условный запрос с If-None-Match возвращает 304;
• единый формат: ответы и ошибки соответствуют схеме, 201 приходит с заголовком Location.

Инструменты называйте те, с которыми работали: Postman или Bruno для ручных проверок, REST Assured или pytest с requests для автотестов, валидация ответов по спецификации OpenAPI. Подчеркните, что проверяете не только статус, но и тело, заголовки и итоговое состояние данных, например повторным GET после изменения.

Где спотыкаются

Проверяют только код ответа. Тогда 200 с ошибкой в теле или без обязательных полей проходит как успех.

Считают отсутствие HATEOAS багом. Большинство реальных API до этого уровня не доходят, и такой дефект означает спор с архитектурным решением, а не найденную ошибку.

Забывают про негативные сценарии: пустое тело, лишние поля, огромные значения, неверные типы. Именно на них API чаще всего отвечает 500.