Проблемы с проектированием внешних API¶
Внешние API приложения могут использовать клиенты 4 типов:
- Веб-приложения с браузерными UI для заказчиков, ресторанов и администраторов
- JavaScript-приложение в браузере
- Мобильные приложения
- Приложения, написанные сторонними разработчиками
Один из вариантов проектирования API заключается в том, чтобы дать клиентам обращаться к сервисам напрямую. Однако на практике такое делают редко из-за следующих недостатков.
- Для извлечения нужных данных клиентам прирдется выполнять несколько запросов. Это неэффективно, и клиенты могут получить отрицательный опыт взаимодействия с сервисом.
- Недостаточная инкапсуляция затрудняет внесение изменений в архитектуру и API
- Сервисы могут задействовать механизмы IPC, которые нецелесообразно или неудобно использовать на клиентской стороне
Проблемы проектирования API для мобильного клиента¶
Предположим, мобильному клиенту нужно отобразить весь объект Order с состоянием изготовления/доставки на текущий момент (представление View Order). В монолитной архитектуре есть конечная точка для получения такого представления в один запрос. В микросервисной архитектуре же детали заказа разбросаны по разным сервисам. Если мобильный клиент будет обращаться к сервисам напрямую, придется делать несколько запросов — выполнять роль API-композитора. Это может привести к следующим проблемам.
Отрицательный опыт взаимодействия из-за того, что клиент выполняет несколько запросов¶
При выполнении нескольких запросов модет увеличиваться время отклика (как минимум на время самого долгого из запросов, если они выполняются параллельно, или, если для некоторых запросов нужно использовать результаты предыдущих, на время ожидания цепочки). Также более интенсивное использование сети потребляет больше энергии, что быстрее сажает аккумулятор устройства.
Недостаточная инкапсуляция требует синхронного обновления кода на серверной и клиентской сторонах.¶
По мере развития приложения могут изменяться как отдельные методы API сервисов, так и число самих сервисов. Соответственно, при подобных изменениях также необходимо выпускать новую версию мобильного приложения, что может занимать часы и дни (так как Google/Apple должны проверить и одобрить новую версию перед релизом в магазине приложений), и не факт, что все пользователи захотят/смогут обновиться до последней версии.
Сервисы могут использовать механизмы IPC, плохо совместимые с клиентами¶
Иногда сервисы могут использовать протоколы взаимодействия, с которыми клиентам сложно работать. Клиентские приложения обычно применяют такие протоколы как HTTP и WebSockets. Однако, у разработчиков сервисов есть выбор помимо этих протоколов, некоторые из которых работоспособны только внутри рабочей локальной сети.
Проблемы с проектированием API для клиентов другого рода¶
Клиенты другого рода — это веб-приложения, JavaScript-приложения и сторонние системы.
Проблемы проектирования API для веб-приложений¶
Традиционные серверные веб-приложения, которые обрабатывают HTTP-запросы браузера и отдают HTML-страницы, находятся в пределах брандмауэра и обращаются к сервисам по локальной сети. Поэтому объединение API здесь не является проблемой. Также не встает вопроса об обновлении, так как все части под контролем одной команды. Таким образом, для веб-сайтов лучше работать с сервисами напрямую.
Проблемы проектирования API для браузерных JavaScript-приложений¶
С одной стороны, JavaScript-приложения легко обновлять при изменениях в API. С другой — они испытывают те же проблемы с латентностью, что и мобильные клиенты. Также обычно бывает, что JavaScript-приложения имеют более развитые интерфейсы, требующие больше информации и должны объединять большее количество сервисов. Поэтому они не смогут эффективно объединять множество API.
Проектирование API для сторонних приложений¶
Сторонним разработчикам крайне важна стабильность предоставляемого интерфейса. Более того, очень трудно заставить сторонние организации перейти на новую версию API. Скорее всего, придется долго (или даже всегда) поддерживать старые версии.
Возлагать ответственность за долгосрочную поддержку обратной совместимости на разработчиков сервисов неразумно. Вместо этого нужно иметь отдельный публичный API, который разрабатывался бы отдельной командой.
Дата создания : 30 июля 2022 г.