Вопросы и ответы для собеседования по REST API (2026): методы, коды состояния и проектирование

Вопросы по REST API проверяют, умеете ли вы проектировать интерфейс, которым другие люди будут пользоваться без сюрпризов. Ниже — 20 вопросов с ответами: от основ до деталей проектирования, которые всплывают на собеседованиях по бэкенду и фулстеку. В правилах использования HTTP-методов мы опирались на определения из RFC 9110.

Основы

1. Что такое REST?

REST — это архитектурный стиль для сетевых систем, построенный вокруг ресурсов, которые идентифицируются URL, обрабатываются небольшим набором стандартных операций и описываются представлениями вроде JSON. REST API не хранит состояние: каждый запрос несёт всё, что нужно серверу для его обработки, поэтому любой сервер может обслужить любой запрос.

2. Что делает API «RESTful» на практике?

• Существительные для ресурсов в URL, например /orders/42, а не глаголы вроде /getOrder
• Стандартные HTTP-методы для действий
• Осмысленные коды состояния
• Запросы без сохранения состояния
• Единообразные представления и структура ошибок

На собеседовании стоит сказать, что мало какие реальные API соблюдают все ограничения REST и что вы стремитесь к предсказуемому поведению.

3. Для чего используются основные HTTP-методы?

«Безопасный» означает, что запрос не меняет состояние сервера. «Идемпотентный» означает, что несколько отправок запроса дают тот же эффект, что и одна.

4. Что означает идемпотентность и почему это важно?

Если запрос повторить, итоговое состояние останется таким же, как после одного запроса. Это важно, потому что сети дают сбои. Если у клиента истёк таймаут на PUT, он может повторить запрос без опасений. А POST, создающий заказ, может создать два, поэтому API часто принимают ключ идемпотентности: клиент отправляет уникальный ключ, и сервер возвращает сохранённый результат, если видит этот ключ снова.

5. PUT или PATCH?

PUT заменяет ресурс целиком тем телом, которое вы отправили, а пропущенные поля очищаются или сбрасываются. PATCH меняет только те поля, которые вы отправили. Используйте PATCH для небольших обновлений и PUT, когда у клиента есть полное представление ресурса.

Коды состояния и ошибки

6. Какие коды состояния вы используете и когда?

Частый дополнительный вопрос — разница между 401 и 403. 401 означает «я не знаю, кто вы», а 403 — «я знаю, кто вы, и вам это делать нельзя».

7. Как API должен возвращать ошибки?

Используйте правильный код состояния и единообразное тело ответа. Хорошее тело ошибки содержит стабильный машиночитаемый код, понятное человеку сообщение и, для ошибок валидации, информацию о том, какие поля не прошли проверку. Не раскрывайте клиентам стектрейсы и внутренние детали.

8. Как вы обрабатываете валидацию?

Проверяйте данные на сервере, даже если клиент тоже их валидирует. По возможности возвращайте все проблемы сразу, чтобы пользователю не приходилось исправлять их по одной, и последовательно используйте 400 или 422.

Проектирование

9. Как проектировать URL для связей между ресурсами?

Вкладывайте один ресурс в другой, когда дочерний имеет смысл только внутри родительского, например /users/7/orders. Не делайте вложенность слишком глубокой. После одного-двух уровней выносите дочерний ресурс на верхний уровень, например /orders/42, и фильтруйте с помощью query-параметров, например /orders?userId=7.

10. Как реализовать пагинацию списка?

Курсорная пагинация — обычный ответ для больших или быстро меняющихся данных. Возвращайте следующий курсор и признак того, есть ли ещё результаты.

11. Как реализовать фильтрацию и сортировку?

Используйте query-параметры, например ?status=open&sort=-created_at. Ограничьте список допустимых полей белым списком, чтобы не раскрывать неиндексированные или чувствительные столбцы и сохранять запросы быстрыми.

12. Как версионировать API?

Что бы вы ни выбрали, избегайте ломающих изменений внутри одной версии. Добавлять поля обычно безопасно, а удалять или переименовывать — нет.

13. Что такое HATEOAS?

Ответы содержат ссылки на связанные действия, чтобы клиент мог сам обнаружить, что ему доступно дальше, вместо жёстко прописанных URL. Это часть определения REST, но мало кто реализует её полностью. Скажите, что вы знаете о ней и что большинство команд вместо этого используют документацию и описание OpenAPI.

Безопасность и производительность

14. Как аутентифицировать API?

Обычные варианты — API-ключи для простого взаимодействия между серверами, bearer-токены, например JSON Web Tokens, и OAuth 2.0, когда пользователь даёт приложению доступ к своим данным. Всегда используйте HTTPS. Держите секреты подальше от URL, поскольку URL попадают в логи.

15. В чём разница между аутентификацией и авторизацией?

Аутентификация — это подтверждение того, кто вы. Авторизация — это решение о том, что вам разрешено делать. Ошибки у них разные: отсутствующий или недействительный токен — это 401, а действительный токен без прав — 403.

16. Как защитить API от злоупотреблений?

Ограничение частоты запросов по ключу или по IP, ограничения на размер запроса, валидация входных данных, таймауты и мониторинг необычного трафика. Возвращайте 429 с заголовком Retry-After, чтобы клиенты знали, когда повторить попытку.

17. Как работает HTTP-кэширование для API?

Ответы могут содержать заголовки Cache-Control, которые указывают, как долго ответ можно переиспользовать. ETag идентифицирует версию ответа. Клиент отправляет его обратно в If-None-Match, и сервер отвечает 304 Not Modified без тела, если ничего не изменилось. Это экономит трафик и снижает нагрузку.

18. Что такое CORS?

Браузеры не дают веб-странице читать ответы с другого origin, если сервер это не разрешил. Сервер отправляет заголовки вроде Access-Control-Allow-Origin, чтобы указать, какие origin могут читать его ответы. Это правило применяет браузер, а не сервер, поэтому оно не защищает API от клиентов, не являющихся браузерами.

Практика

19. REST, GraphQL или gRPC?

Лучший ответ называет ситуацию, а не победителя.

20. Как документировать и тестировать API?

Опишите его с помощью спецификации OpenAPI, которая может генерировать документацию и клиентский код. Тестируйте на трёх уровнях: модульные тесты для логики, интеграционные тесты с реальной базой данных и контрактные тесты, чтобы ловить ломающие изменения. Проверяйте и случаи ошибок, например некорректный ввод и истёкшие токены.

Как готовиться

1. Умейте спроектировать небольшой API на доске, например список задач или систему заказов, с URL, методами, кодами состояния и одним ответом с ошибкой.
2. Знайте идемпотентность и пагинацию назубок. О них спрашивают чаще всего.
3. Подготовьте историю о том, как вы создавали или использовали API, и об одной ошибке, которую вы бы не повторили в следующий раз.

Для дополнительной практики смотрите наши руководства по вопросам на собеседовании по Spring Boot, вопросам на собеседовании по Node.js, вопросам на собеседовании по системному дизайну и вопросам на собеседовании по компьютерным сетям.

Практикуйтесь вслух и своими словами. Расшифровка после этого покажет, где вы растекались мыслью или упустили суть. Соблюдайте правила работодателя насчёт инструментов ИИ на любом живом собеседовании или оценочном задании.