Отдавать JSON не значит иметь API
Прежде всего, нужно уточнить несколько вещей об API. Отдающий JSON бэкенд — это не обязательно API. Управление API в целом, версионирование для обратной совместимости, управление жизненным циклом и следование архитектурным стилям, таким как REST, требуют усилий. И это сверх самого главного — бизнес-требований.
Бэкенд никогда не предназначался для API
Я убеждал себя, что такие бэкенды и есть API. Возможно, в начале разработки может отсутствовать функциональность вроде версионирования, но со временем она появится.
На самом же деле чистые конечные точки и методы RESTful вряд ли станут реальностью, но они накапливаются в виде технического долга. Звучит знакомо, правда?
Такое мышление вводит в заблуждение, особенно среди архитекторов, разрабатывающих бэкенд веб-приложений. Это потому, что бэкенд никогда не должен был стать API.
Даже если вы создадите веб-бэкенд как API, есть несколько общих проблем. Первая проблема: веб-приложение требует вызова нескольких конечных точек для выполнения снижающего производительность действия. Если поддерживается управление версиями, то фронту может потребоваться справиться со сложностью вызова разных версий. Кроме того, если бэкенд спроектирован как набор сервисов (микросервисов), то сложность фронтенда будет расти.
Я понимаю, что это крайние случаи, но серьёзно подумайте над ними.
Не думайте о бэкенде как об API
Всем известно, что для создания бизнес-функциональности веб-приложений вместе работают разные команды. Хотя технически возможно выпускать фронтенд и бэкенд раздельно, часто нужно выпускать их одновременно. Да, можно разделять команды на фронт и бэк, но я бы предпочёл делить их по функциональности. Каждая команда отвечает за весь стек. При таком делении предоставляется возможность лучше управлять функциями приложения.
А теперь представьте, что в приоритете API. Тогда командам нужно решать такие проблемы, как управление версиями, стратегия развития API, совместимость бэкенда и фронтенда… и это — приоритет. А первоочередная задача приложения — обеспечение ценности бизнеса за счёт максимально быстрого и эффективного выпуска функций.
А что с переиспользованием?
Следующий важный вопрос связан с менталитетом переиспользования. Что, если мы создадим единый API бэкенд и повторно используем его для веба, мобильного приложения и сторонних интеграций?
Это ошибка. Как правило, мобильные приложения используют только некоторые функции из веба, оптимизированные исходя из частоты или специфики использования. То же верно для сторонних интеграций.
Стороннему API может потребоваться доступ ко всем данным из конечной точки. Для одной и той же конечной точки могут потребоваться ограничения для веб-приложений. Важно понимать: требования к аутентификации и авторизации могут быть разными в зависимости от характера интеграции (например, B2B или B2C).
Я хотел подчеркнуть конкретные конечные точки для случаев выше, а не пытаться насильно изменить образ мышления. Если видите стандартные бизнес-функции, то переиспользуйте внутренний код в форме библиотек, а не API.
О сторонних решениях и мобильных приложениях
В отличие от серверной части веб-приложения, имеет смысл создать мобильную серверную часть как API, поскольку вы не можете напрямую обновить версию приложения в телефоне пользователя, если есть критические изменения API. Поэтому для разных версий мобильных приложений нужны разные версии API. Снова то же применимо к сторонним интеграциям. Третьи стороны не будут вносить изменения немедленно, если вы меняете API. Здесь вам нужно больше контроля и управления, поэтому разработка отдельного API имеет смысл.
Итог
Не рассматривайте серверную часть веб-приложения как API. Если делаете это, то только сознательно, понимая его ограничения. Разделите команды с ориентиром на бизнес, а не фронтенд и бэкенд. Каждая команда должна иметь возможность создавать ценность бизнеса с минимальной зависимостью от других.
Если область применения приложения широкая, рассмотрите возможность разбиения на несколько приложений и бэкендов. Каждая команда должна работать на фронтенде и бэкенде. Вы также можете создать микросервисы для бэкенда, но убедитесь, что начинаете с небольшого набора сервисов.
И помните: то же самое не относится к мобильным и сторонним приложениям. Убедитесь, что создаёте управляемый в целом программный интерфейс, также обладающий управлением версиями и жизненным циклом.
Перевод статьи Ashan Fernando: Your Web App Backend is NOT an API. Let’s Face it!
