Привычные решения и новшества
Для проектирования и мониторинга API есть много уже знакомых разработчикам API Design-инструментов: Postman, SwaggerHub, Stoplight, Readme, MuleSoft и другие, в том числе тесно привязанные к облачным провайдерам.
Сейчас разрабатываются и другие инструменты проектирования API: Redocly, Insomnia, Archbee, Cruderra и другие. В них пока нет полноценных инструментов мониторинга API, но это дело времени.
На определенном этапе перед командой разработки появляется задача сравнения проекта API с тем, что происходит в бэкенде на самом деле. И тогда инструменты тестирования и мониторинга выходят на первый план. Благодаря им можно не только отследить явные ошибочные ситуации использования API, но и выявить проблемы производительности на стыке задач APIOps, TestOps и DevOps.
Но если слишком увлечься вопросами автоматического тестирования и мониторинга, можно легко забыть про основную цель разработки. Важно наладить связь между изначальными требованиями проекта и его реальным воплощением. Архитектору проекта нужно сохранять контроль между тем, что задумано, и тем, что действительно пошло в продакшн. Это помогает актуализировать проект, отследить реальное поведение пользователей, выявить повторения, сильные и слабые стороны, чтобы предложить улучшенную версию API.
Причем контролировать API и целостность сценариев его использования нужно непрерывно, на протяжении всех витков спирали жизненного цикла разработки.
«Инструменты тестирования и мониторинга выходят на первый план»
На что нужно обращать внимание при сравнении проекта и реальности
В первую очередь, проверяют работу нисходящей цепочки контроля и отвечают на пять вопросов:
Какие есть пользовательские истории и какие из них содержат ошибки?Какие API Endpoints возвращают ошибочный статус? Сколько таких статусов?Ошибочная реакция Response Status на запрос верна? Или вызвана внутренней ошибкой обработки?Насколько валидны входящие и исходящие модели данных (DataModel) и заголовков (Headers)? Насколько они соответствуют изначальным требованиям?Верное ли значение поля (Field) передается в модели данных? Не нарушаются ли ограничения? Выставленные ограничения необходимы и достаточны?
Если ответы на эти вопросы есть, — это базовая степень контроля работы API продукта.
Но API — лишь внешний интерфейс взаимодействия с его потребителями. При реализации серверной части нужно учитывать множество входных точек, запускающих вычисления:
API Endpoints (в том числе HTTP, gRPC, WebSockets, server-sent events, webhooks и др.);брокеры сообщений (Kafka, Rabbit MQ и др.);задачи по расписанию (jobs или workers).
Для учета этих точек недостаточно одних инструментов API Design. Обычно применяют дополнительные инструменты мониторинга — готовые или настроенные под себя (например, при помощи Grafana + Prometheus). Это помогает выявить скрытые накапливающиеся проблемы, уведомить команду разработки и принять своевременные меры.
Также нужно обращать внимание на сбор не только технических метрик, но и поведенческих. Это важно для анализа использования сценариев и входных точек API, а также поведения самих пользователей. Так продуктовая команда получает обратную связь, которая позволяет улучшить сам API. В том числе по вопросам безопасности и монетизации.
Есть уверенность, что все работает. Какие тесты необходимо провести?
ИТ-отрасли известна классическая пирамида тестирования, описывающая комплексный подход в покрытии IT-продукта тестами (по ISTQB):
модульное;интеграционное;системное;приемочное.
В зависимости от продукта, его архитектуры и степени развития можно применять различные подходы и глубину тестирования.
Также для уверенности в работоспособности продукта нужно обеспечить закрытие инфраструктурных вопросов:
включение автотестов в этапы сборки проекта в CI/CD;подключение рассылки оповещений (alerts) о критических состояниях системы;настройка мониторинга разрабатываемых сервисов, а также используемых внутренних и внешних продуктов;фиксация исключений и логов в отдельных системах для дальнейшего отслеживания и восстановления событий.
Выявлять проблему лучше еще до того, как пользователь сообщит о ней или уйдет. К счастью, ИТ-сообщество накопило открытую базу знаний в области тестирования. Если применять лучшие практики, то система будет работать как часы.
«Выявлять проблему лучше еще до того, как пользователь сообщит о ней или уйдет»
Над чем еще стоит поработать: будущее в этой сфере
Для разового решения задачи сравнения проекта API с его реальным воплощением вполне достаточно существующих API Design инструментов.
Однако для более глубокого контроля API требуется нечто большее. Например, Continuous API Design с инструментами мониторинга и тестирования. А если смотреть еще на один уровень глубже, то также необходимо контролировать backend, выполняющий основную работу для обслуживания внешнего интерфейса API.
С каждым годом инструменты контроля создания ИТ-продуктов совершенствуются. Появляются новые сервисы, которые делают жизнь разработчиков легче. Несмотря на внешние потрясения, ИТ-сфера сохраняет устойчивую динамику развития и потребность в удобных инструментах повышения эффективности будет только расти.
Читать далее:
«Джеймс Уэбб» прислал фото столкновения двух огромных галактик
«Бесполезная» бактерия на Земле обеспечит жизнь колонизаторам Марса
На пирамиде в Китае нашли портрет «царя предков». Он правил более 4 000 лет назад