[Перевод] Что такое управление API?06.02.2019 19:34

Всем привет! Друзья, уже 21 февраля у нас стартует курс «Backend разработчик на PHP». В преддверии запуска курса хотим поделиться с вами переводом одного интересного материала. Приятного прочтения!

В октябре на конференции NGINX Conf 2018 мы анонсировали новый модуль управления API для контроллера NGINX. С этим продуктом мы укрепляем свои позиции в качестве самого развернутого шлюза API в отрасли — миллионы сайтов уже используют NGINX Open Source и NGINX Plus для обеспечения безопасной передачи трафика между серверными приложениями и потребителями API, предоставляемыми этими приложениями.

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

l5wfgobot8mwhwfgbc3ug7grgvc.png

Управление API охватывает весь жизненный цикл ваших API
(На рисунке: начиная сверху по часовой стрелке — Определение и публикация, Безопасность, Управление трафиком (шлюз API), Постоянный мониторинг и поддержка, Аналитика количества доступа к API. Адаптация (Dev-портал);
в центре — Управление API)

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

Ключевые концепции

Управление API имеет свои собственные понятия и терминологию:

  • Внутренние API — внутренние API доступны только для других приложений (и их разработчиков) внутри предприятия, но не для внешних пользователей. Внутренние API-интерфейсы помогают открыть данные и развивать сотрудничество между функциональными подразделениями в рамках предприятия. Вот наглядный пример: прежде чем оказывать помощь клиентам, группа технической поддержки предприятия должна определить, есть ли у клиента действующий контракт на поддержку. Эта информация уже хранится в корпоративной системе управления взаимоотношениями с клиентами (CRM), такой как Salesforce. Вместо того, чтобы дублировать информацию в своей собственной базе данных, приложение поддержки клиентов вызывает внутренний API CRM.
  • Внешние API — внешние API доступны пользователям за пределами вашего предприятия. Они предоставляют средства для налаживания партнерских отношений со сторонними разработчиками, а также всей вашей бизнес-экосистемой поставщиков, дистрибьюторов, посредников и даже клиентов. Внешние API также позволяют предприятиям генерировать новые источники дохода, используя инновационные бизнес-модели. Карты Google являются наглядным примером. Многие сторонние веб-сайты и приложения встраивают карту Google, чтобы помочь конечным пользователям точно определить местонахождение магазина или проложить маршрут. Доступ к карте для конечного пользователя не стоит ничего, но после определенного количества кликов Google взимает плату с сайта или приложения за каждый вызов API.
  • Определение и публикация. Решения по управлению API предоставляют интуитивно понятный интерфейс для определения значимых API, включая базовый путь (URL), ресурсы и конечные точки.
    • Ресурсы имеют основополагающее значение для любого определения API; они являются абстракцией информации, над которой API выполняет операции. Примеры ресурсов — документы и идентификаторы клиентов. API вызывается для получения этой информации.
    • Конечные точки (endpoint) указывают, где расположены ресурсы. API имеют базовый URL-адрес, к которому добавляются пути конечных точек. Все конечные точки API относятся к базовому URL.

  • Например, в конечной точке API https://app.enterprise.com/v1/inventory/, /v1 — это базовый путь, а /inventory — ресурс.
  • Решения по управлению API позволяют авторам API публиковать API-интерфейсы в различных средах, например, предназначенных для производство, тестирования или подготовки. Это обеспечивает согласованность для каждой среды и предотвращает неправильную настройку. Решения также автоматизируют создание новых API и модификацию существующих.
  • API-шлюз (API gateway) — Как уже упоминалось ранее, API-шлюзы защищают и обеспечивают передачу трафика между вашим бэкэндом и потребителями ваших API. Функциональность шлюза включает аутентификацию вызовов API, маршрутизацию запросов к соответствующим бэкэндам, применение ограничений скорости для предотвращения перегрузки ваших систем или смягчения DDoS-атак, разгрузку трафика SSL/TLS для повышения производительности и обработку ошибок и исключений.
  • Микрошлюз (microgateway)- многие решения имеют централизованную, тесно связанную плоскость данных (шлюз API) и плоскость управления (инструмент управления API). Все вызовы API должны проходить через плоскость управления, что добавляет задержку. Шлюз API в этом архитектурном подходе неэффективен при обработке трафика в распределенных средах (например, внутрисервисного трафика в среде микросервисов или обработки IoT-трафика для поддержки анализа в реальном времени). Следовательно, для управления трафиком, когда потребители и поставщики API находятся в непосредственной близости, поставщики устаревших решений ввели дополнительный программный компонент — микрошлюз для обработки вызовов API.
  • Аналитика API — По мере того как ваши API становятся популярными, вы должны убедиться, что они обеспечивают ценность для ваших пользователей, а также соответствуют вашим бизнес-целям. Вот где аналитика становится критически важной. Решения по управлению API обеспечивают крайне необходимое понимание с помощью визуализаций (таких как информационные панели и отчеты) метрик и использования API, информируя вас (в качестве примеров), какие API используются чаще или реже, как меняется трафик API с течением времени, и какие разработчики являются лучшими API потребители. Аналитика API позволяет владельцу API-бизнеса, иногда называемому «Менеджер API-продуктов» (API Product Manager), получить глубокое представление о производительности программы API.
  • Аналитика также важна для устранения неполадок. Решения по управлению API обеспечивают глубокое представление о рабочих показателях для каждого API. Эти метрики позволяют командам инфраструктуры и эксплуатации отслеживать и устранять проблемы с производительностью и безопасностью. Вот примеры вопросов, ответить на которые может помочь аналитика:
    • What is the status and uptime of all my API gateway instances?
    • When do we see slowdowns for an API?
    • When are HTTP errors occurring for an API?
    • Каково состояние и время работы всех моих экземпляров API-шлюза?
    • Когда мы наблюдаем замедления для API?
    • Когда возникают ошибки HTTP для API?

  • Безопасность API — безопасность является критическим аспектом инфраструктуры API. Без надежной защиты любой может получить доступ к вашим данным и API, и ввести злонамеренное поведение, вызвав запрос к незащищенной API. Безопасность API включает в себя следующие элементы:
    • Аутентификация — Аутентификация относится к процессу надежного определения личности вызывающего абонента. Ключи API — это стандартный механизм аутентификации и идентификации абонентов, которые хотят получить доступ к API. Решения по управлению API предоставляют поставщикам API интерфейс для генерации API-ключей, которые затем могут быть переданы сторонним разработчикам для использования при вызовов API. OAuth — это широко используемый механизм аутентификации.
    • Авторизация — Авторизация относится к процессу определения того, какие привилегии или уровни доступа предоставляются пользователю. Один из способов авторизации пользователей — через JSON Web Tokens (JWT). JWT — это токены доступа, которые заявляют утверждения (claims — терминология JWT для отдельных привилегий). Например, JWT, представленный клиентским приложением, может включать утверждение, разрешающее доступ к одному конкретному ресурсу. Если клиентское приложение пытается получить доступ к любым другим ресурсам, возвращается ошибка HTTP 403 Forbidden error is returned.
    • Управление доступом на основе ролей (RBAC — Role‑based access control) — RBAC относится к определению ролей пользователей с определенными привилегиями. Например, сотрудники Infrastructure & Operations обычно не несут ответственности за создание и публикацию API, а только за мониторинг и устранение неполадок. Таким образом, им назначена роль, которая имеет только эти привилегии. Точно так же только Менеджеру API-продуктов назначается роль, которая имеет доступ к API-аналитике.
    • Ограничение скорости — ограничение скорости относится к наложению ограничения на количество запросов, которые запрашивающий агент может сделать в течение определенного периода времени (например, 10 000 запросов в секунду). Ограничения скорости предотвращают перегрузку ваших бэкэнд-систем и помогают смягчить DDoS-атаки. Решение для управления API предоставляет интерфейс для определения ограничений скорости, которые затем применяет API-шлюз. Ограничения скорости также позволяют предлагать многоуровневые уровни обслуживания (например, клиенты уровня Gold могут делать 10 000 запросов в секунду, а клиенты уровня Silver — 5000).

  • Портал для разработчиков. Портал для разработчиков — это онлайн-сайт, где вы публикуете ресурсы, которые способствуют быстрой адаптации ваших потребителей API, такие как каталог внешних API, полная документация и примеры кода. Портал для разработчиков также позволяет сторонним разработчикам регистрировать свои приложения и получать API-ключи и JWT. Некоторые решения также предоставляют механизм взаимодействия между разработчиками, которые используют ваш API. Хорошо разработанный портал для разработчиков имеет решающее значение для успеха вашей API-программы.

Управление NGINX API: использование основополагающего для отрасли API-шлюза

NGINX уже является самым распространенным в отрасли API-шлюзом — в нашем недавнем опросе 40% наших клиентов сообщили о том, что они используют NGINX в качестве API-шлюза.

Новый модуль управления API для контроллера NGINX, который скоро будет выпущен, сочетает в себе мощь и эффективность NGINX Plus в качестве шлюза API с новой функциональностью уровня управления. NGINX контроллер позволяет командам Infrastructure & Operations и DevOps определять, публиковать, защищать, отслеживать и анализировать API, сохраняя при этом контроль над разработкой API. Широкие возможности мониторинга и оповещения помогают обеспечить доступность, производительность и надежность приложений. NGINX контроллер обеспечивает глубокое представление о ключевых показателях, позволяя командам Infrastrastructure & Operations и DevOps в первую очередь избегать проблем с производительностью и быстро устранять любые возникающие проблемы.

Наш подход к управлению API отличается от традиционных решений. В отличие от этих решений, API-шлюз NGINX Plus (плоскость данных) не требует постоянного подключения к контроллеру NGINX (плоскость управления), поэтому трафик времени выполнения API изолирован от трафика управления. Контроллер NGINX устраняет необходимость в локальных базах данных или дополнительных компонентах, которые могут создавать ненужную сложность, задержку и точки отказа для API-шлюзов NGINX Plus. Это максимизирует производительность за счет уменьшения среднего времени отклика для обслуживания вызова API и минимизирует объем и сложность шлюза. Отсоединение плоскости данных от плоскости управления дает вам гибкость в развертывании такого количества экземпляров API-шлюза, которое требует архитектура вашего приложения. Контроллер NGINX дает вам свободу выбора правильного развертывания для внутренних и внешних потребностей API с помощью легкого, простого и высокопроизводительного решения, которое полностью использует возможности плоскости данных NGINX Plus.

Технология NGINX поддерживает порталы разработчиков Capital One — Devexchange. Это позволило Capital One масштабировать свои приложения до 12 миллиардов операций в день с пиковыми значениями в 2 миллиона операций в секунду с задержками всего 10–30 миллисекунд. NGINX также поддерживает портал Adobe для разработчиков Adobe I/O. Adobe I/O позволяет разработчикам интегрировать, расширять и создавать приложения на основе продуктов и технологий Adobe с использованием API. Платформа обрабатывает миллионы запросов в день с незначительной задержкой.

Вот такой получился перевод, как вам? Ждём ваши комментарии и традиционно приглашаем на открытый урок, который 11 февраля проведет наш преподаватель Игорь Саханков.

© Habrahabr.ru