Django фреймворк позволяет очень легко и быстро создавать View, но он не знает, зачем ты это делаешь. Django неважно, сделаешь ли ты один endpoint на всё или построишь сложную вложенную структуру — всё это твоя забота.
В статье ты познакомишься с тремя значимыми подходами к проектированию API, при помощи которых станет ясно почему один API очень приятный и "очевидный", а другой вызывает боль чуть ниже копчика.
API - Application Programming Interface. Как программы общаются между собой
API First
При создании IT-продукта мы постепенно снижаем неопределенность: описываем целевую аудиторию продукта, описываем их основную проблему, определяем форму продукта, функциональный состав продукта, архитектурное видение и так далее до конкретной строчки кода.
Вы никогда не сумеете решить возникшую проблему, если сохраните то же мышление и тот же подход, который привёл вас к этой проблеме. Альберт Эйнштейн
Конкретный код — это последний уровень, который влияет на качество потребления продукта, но если в один день продакт-менеджер решит, что ошиблись с аудиторией, то весь этот «конкретный код» полетит в мусорку.
Чтобы это происходило реже, применяется API First — это философия, при которой API рассматривается как (внутренний) продукт, а не как побочный результат разработки:
- Основной продукт — не сумма твоих View, а сумма API, реализация которых "неважна"
- API — внутренний продукт компании, со своим описанием пользователя/системы, ожиданиями
- Документация API — это описание продукта, которое ожидают пользователи
- Изменение API — важная веха развития продукта и изменения не должны ломать пользователей
В API First разработчик не просто поставляет код "тесты прошли - катим на прод", а задаёт вопросы: "Кто и как будет пользоваться? Это точно нужно делать?"