Некоторые мысли об управлении API

API
Некоторые мысли об управлении API

предисловие

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

Зачем вам нужно управление API

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

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

что нам действительно нужно

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

  1. Описание уместно
  2. Разумное разделение
  3. Синхронизация по времени
  4. Прошел тест
  5. легко использовать

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

как управлять

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

  • Инструменты лучше всего сочетаются с кодом (привыкание).
  • Пройти испытание (ограничение).
  • Иметь право определять некоторые интерфейсы (предоставлять определенные права).

Анализ платформы

онлайн-продукт

Существует множество таких продуктов, которые в основном можно разделить на бесплатные и платные, а некоторые продукты предоставляют больше дополнительных услуг, таких как мониторинг, автоматизированное тестирование и т. д.

Преимущество

  1. Не требует обслуживания сервера
  2. Предоставляет функции совместной работы в команде
  3. Обеспечить онлайн-тест интерфейса
  4. Уведомление об изменении интерфейса (не обязательно)
  5. Управление несколькими проектами

недостаток

  1. Платформа может прекратить техническое обслуживание в любое время
  2. Интерфейсы нуждаются в ручной синхронизации
  3. Форматы интерфейсов основных платформ неоднородны, и миграция представляет собой проблему.
  4. Контракт интерфейса не гарантируется (проходит ли он тест? Правильно ли он сформирован?)

Интеграция с фреймворком

Интеграция фреймворка относится к интеграции фреймворка автоматической генерации документов API в среду разработки.В настоящее время на основе spring в основном springfox-swagger2 и spring rest doc.

Springfox-Swagger2

недостаток

  1. Инвазивный
  2. Добавьте небольшую стоимость обучения

Преимущество

  1. Безопасная определяемая аутентификация доступа к интерфейсу
  2. Код — это документация
  3. Красивый интерфейс
  4. предоставить тест
  5. Сообщество обеспечивает интеграцию с Spring-Boot
Spring REST Doc

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

недостаток

  1. Добавьте небольшую стоимость обучения
  2. Документация требует небольшой ручной настройки, но, к счастью, настройка относительно проста.
  3. Выполнение тестов API перед публикацией интерфейса занимает некоторое время.

Преимущество

  1. Безопасный, выбираемый объем обмена документами
  2. неинвазивный
  3. Контракт интерфейса (автономная html-документация API может быть создана только после прохождения теста API)
  4. Код — это документация
  5. весенняя экология, легко интегрируется

самодельный

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

Преимущество

  1. управляемый
  2. настраиваемый

недостаток

  1. Требуется обслуживание сервера
  2. Интерфейсы нуждаются в ручной синхронизации
  3. Контракт интерфейса не гарантируется (проходит ли он тест? Правильно ли он сформирован?)

Суммировать

В статье изложены мои собственные взгляды на управление API, а также дан краткий анализ некоторых инструментов API, представленных на рынке, а также обобщены преимущества и недостатки различных продуктов. Цель управления API — облегчить совместную работу команды. Основываясь на этом понимании выше, я действительно обнаружил, что Spring REST Doc подходит лучше всего.