Методы получения контроля над неконтролируемым разрастанием API

Гетти Изображения

Если его не контролировать, большой портфель API может быстро стать большой проблемой и дорогостоящей ответственностью для бизнеса. Без четко определенной стратегии API и стандартизации приложения могут легко выйти из-под контроля и вызвать разрастание API.

Когда происходит разрастание API, может проявиться неэффективность, такая как дублирование усилий по разработке избыточной функциональности приложений, что потребует более высоких инвестиций в обслуживание и увеличит сложность системы. Потребность в обратной совместимости для многих потребителей может быть чрезвычайно сложной и дорогостоящей. Множественные источники достоверной информации также могут привести к конфликтам данных, что приводит к плохому опыту и двусмысленности, что может снизить эффективность внедрения.

В этой статье мы рассмотрим несколько всеобъемлющих стратегий, которые команды разработчиков программного обеспечения могут реализовать, чтобы предотвратить разрастание API или, при необходимости, восстановить контроль над уже плохо управляемым портфелем API.

Управление бесконтрольным распространением API требует целенаправленных усилий со стороны групп разработчиков программного обеспечения, чтобы гарантировать, что они могут свести к минимуму общую сложность, стоимость изменений и аварийное обслуживание.

Решение проблемы разрастания API начинается с определения общей степени влияния API на операции и потребление ресурсов. Зачастую API могут взаимодействовать с программными объектами как внутри организации, так и за ее пределами. Масштаб воздействия API часто ограничен, когда потребители, внутренние или внешние, явно интегрированы с ними.

Общедоступные API могут представлять собой значительно более высокую степень сложности управления. Помимо классификации по масштабу воздействия, которая может включать любое количество компонентов и конечных точек, находящихся вне контроля организации, единый общедоступный API часто может включать в себя несколько форматов данных, стандартов безопасности и протоколов связи. Таким образом, крайне важно определить степень фрагментации во время реализации контракта и протокола.

Иногда API необходимо мигрировать между системами в течение их жизненного цикла. Чтобы обеспечить плавный переход, группам разработчиков программного обеспечения необходимо будет подготовить API-интерфейсы перед миграцией, чтобы гарантировать сохранение желаемого состояния. Чтобы уменьшить проблемы с переходом, может также потребоваться калибровка миграции, чтобы API-интерфейсы переносились медленно, а не массово. В этом отношении могут пригодиться некоторые базовые методы управления версиями API, например, позволяющие потребителям переходить на более новые версии, в то время как старые контракты устарели. Команды также могут создавать доступные библиотеки для популярных сред выполнения, создавать уровни совместимости для новых API или добавлять флаги функций, специфичные для потребителя, чтобы обеспечить плавную миграцию.

Как только существующая ситуация и влияние будут хорошо поняты, последующие шаги должны быть сосредоточены на сближении существующих стандартов. Этот этап можно разделить на три «подэтапа», которые мы рассмотрим ниже.

Командам необходимо регулярно измерять и анализировать использование API во всех средах. Области, где контроль над потребителями API отсутствует или незначителен, может потребовать помощи инструментов или платформ управления API, которые обеспечивают поддержку таких возможностей, как макетирование. Определите основные области воздействия, критические функции и все существующие форматы API.

API в больших неуправляемых портфелях часто могут проявлять избыточное поведение, которое приводит к дублированию источников информации и усилий по разработке. Важно устранить неоднозначность источников, установив четкие границы доменов для классификаций API и, что, возможно, более важно, управленческих обязанностей. Для этого может потребоваться создание новых API, которые являются «консолидированными версиями» старых, прекращение поддержки существующих API, которые считаются избыточными, или просто обновление контрактов существующих API, чтобы сузить их область применения.

После того как произойдет функциональная консолидация, важно установить четкие соглашения, соответствующие потребностям и целям бизнеса, которые в конечном итоге определят путь для переходов, а также новых разработок. Документирование и графическое представление этих отношений будет иметь большое значение для достижения более широкого консенсуса по таким вещам, как структуры контрактов и лежащие в их основе протоколы.