Как отличить системного аналитика, который знает REST по шпаргалке, от того, кто действительно проектировал AP

Как отличить системного аналитика, который знает REST по шпаргалке, от того, кто действительно проектировал API?

По ответам на 3 задачи.

1. **Не путать ресурс и действие**
Если в интерфейсе появляются глаголы там, где должен быть объект, — это первый сигнал. Хороший API строится вокруг сущностей и их состояний, а не вокруг «сделать/отменить/подтвердить».

2. **Думать про ошибки заранее**
PATCH, 409, валидация, конфликт версий — это не «детали для потом». Это часть дизайна. Если команда не договорилась, что считается конфликтом и как его видит клиент, интеграция быстро превращается в спор между backend и frontend.

3. **Проверять себя на живых кейсах**
FinTech и e-commerce почти всегда вскрывают слабые места: идемпотентность, повторные запросы, статусные модели, обратную совместимость. Именно там видно, где есть системное мышление, а где — только знание терминов.

Мини-чек-лист для собеседования:
- можно ли объяснить API без абстракций;
- есть ли логика в кодах ошибок;
- продуманы ли спорные сценарии;
- понимает ли кандидат, что клиенту важно не «правильно по учебнику», а «предсказуемо в проде». 🔍

Хороший REST — это не про красивую схему. Это про ясные правила, которые выдерживают реальную нагрузку.