API
REST-моделирование: тест на свободное припоминание
Припоминание сильнее перечитывания. Для каждого промпта проговори или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания делает материал устойчивым.
Восстанови ключевые ходы юнита — существительные vs глаголы, паттерны не-CRUD переходов, пределы вложенности, разделение representation/resource, идемпотентность и прагматику HATEOAS — не подглядывая в урок.
- 01Почему «глагол живёт в HTTP-методе, а не в URL» — основной ход REST, и что теряется в тот момент, когда ты пишешь POST /createOrder?
- 02В реальных доменах есть действия, не являющиеся create/read/update/delete — отмена, публикация, возврат. Назови два чистых паттерна и анти-паттерн, которого избегать.
- 03Каково senior-правило для глубины вложенности и какие две проблемы создаёт глубокая вложенность?
- 04Различи resource и representation и объясни, почему «не сериализовать строки БД напрямую» — решение с наибольшим рычагом в дизайне API.
- 05Определи идемпотентность, скажи, какие HTTP-методы идемпотентны, и объясни, как сделать создание через POST безопасно ретраимым.
- 06Что такое HATEOAS, почему это теоретический эндгейм и почему почти никто его не отгружает?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: моделируй существительные и держи глагол в методе; не-CRUD переходы становятся охраняемыми action- или transition-ресурсами, а не записываемым полем status; вкладывай мелко и используй expansion против chatty-экранов; сериализуй через mapping-слой, чтобы representation был контрактом, которым ты владеешь, а не твоей схемой БД; POST не идемпотентен, поэтому используй idempotency key для безопасных ретраев; а HATEOAS — изящная теория, без которой level-2 REST, что почти все и отгружают, обычно обходится.