вопрос на собесе: как спроектировать REST API так, чтобы потом не утонуть в костылях?

вопрос на собесе: как спроектировать REST API так, чтобы потом не утонуть в костылях?

Проверка простая: если человек отвечает только про GET/POST и забывает про контракты, ошибки и версионирование — REST он читал, но не проектировал.

3 шага, чтобы не облажаться:

1. Сначала ресурсы, потом методы
Не «какие эндпоинты сделать», а «какие сущности живут в системе». Заказ, платеж, статус, возврат — это основа. И только потом решаем, где нужен POST, где PATCH, а где идемпотентный PUT.

2. Пропишите ошибки до реализации
409 — конфликт, 400 — плохой запрос, 404 — не нашли, 422 — данные формально есть, но бизнес-правило сломано. Если кандидат путает это на whiteboard, в проде у него будет хаос.

3. Думайте о будущем API
Фильтры, пагинация, версионирование, частичные обновления, backward compatibility. Хороший API не «работает сейчас», а не ломается через полгода 😈

Мини-чеклист для собеса:
— назвал ресурсы
— объяснил выбор метода
— описал ошибки
— учел идемпотентность
— подумал про изменения контракта

Если хотите отличаться от «учил REST по учебнику», отвечайте как инженер, который уже чинил последствия чужого дизайна.