Вопрос проверяет понимание того, почему “один endpoint на всё” усложняет систему, несмотря на внешнюю гибкость
Универсальные endpoint’ы выглядят гибко, но быстро теряют прозрачность. Они усложняют валидацию, документацию и тестирование. Поведение становится зависимым от множества флагов и параметров. Ошибки труднее диагностировать, а изменения чаще становятся breaking. В итоге поддержка такого API дороже, чем у специализированных endpoint’ов.
Универсальный endpoint — это API-точка, поведение которой существенно меняется в зависимости от входных параметров или режима работы.
Скрытая сложность
Большое количество условной логики.
Трудно понять, какой сценарий будет выполнен.
Слабая типизация и валидация
Множество опциональных полей.
Ошибки выявляются слишком поздно.
Проблемы с документацией
Контракт становится размытым.
Клиенты не понимают допустимые комбинации параметров.
Рост связанности
Изменение одного сценария затрагивает другие.
Повышенный риск регрессий.
Сложность тестирования
Экспоненциальный рост кейсов.
Сложно покрыть все ветки логики.
Для read-only запросов с фильтрацией.
Для внутренних API с контролируемыми клиентами.
Универсальные endpoint’ы редко масштабируются по сложности: чаще всего несколько простых и явных endpoint’ов надёжнее и дешевле в поддержке.
