Спроектировать API для заказов
Вопрос
Как бы ты спроектировал REST API для интернет-магазина: заказы, позиции заказа, отмена, список с фильтрами?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Ресурсы: /orders, /orders/{id}, /orders/{id}/items, существительные во множественном числе
Методы и коды: POST 201 с Location, PATCH, DELETE 204, 404, 409, 422
Отмена как действие: POST /orders/{id}/cancel, не GET
Список: фильтры и сортировка в query, cursor-пагинация с лимитом
Надёжность: Idempotency-Key на создание, ETag и If-Match для конкурентных правок
Версия /v1 и единый формат ошибок
Что могут спросить следом
- Как отдать заказы вместе с позициями одним запросом?
- Что изменится, если клиентов станет десяток с разными потребностями?
- Как защитить API от слишком больших limit?
Разбор
Начну с ресурсов: заказы по /v1/orders и /v1/orders/{id}, позиции как вложенный ресурс /orders/{id}/items. Создание через POST с ответом 201 и Location, частичное изменение через PATCH, удаление позиции через DELETE с 204. Отмена это бизнес-действие с побочными эффектами, поэтому POST /orders/{id}/cancel, и если заказ уже отправлен, отвечаю 409. Список заказов с фильтрами в query вроде status и диапазона дат, сортировкой и cursor-пагинацией, лимит ограничиваю сверху, например 100. Для создания заказа принимаю Idempotency-Key, чтобы ретраи не плодили дубли, а для правок использую ETag и If-Match. Ошибки отдаю в формате Problem Details. Чтобы не делать лишних запросов, можно поддержать параметр expand=items.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.