Основатели компании «Cruderra», занимающейся созданием нового инструмента для разработчиков для ускорения построения API, Алмаз и Ринат Хабибуллины утверждают: гарантированный способ получить высокую оценку при прохождении технологического аудита готового продукта – еще на этапе его планирования поставить в приоритет создание API с учетом релевантных новаций в отрасли.
Дорого продать продукт без качественного API – утопия
Технологический аудит продукта – например, мобильного приложения и его серверной части – состоит из множества шагов проведения оценки с различных сторон. При наличии в продукте клиент-серверного взаимодействия аудитором в первую очередь будет запрошен API.
«API и документация к нему раскрывают один из слоев детализации технического исполнения сервиса, и позволяют аудитору оценить набор функциональности сервиса и его ограничения, определить степень зрелости проекта, применяемые практики, чистоту исполнения, ориентируясь на подходы предметно-ориентированного проектирования (DDD), прямо или косвенно определить взаимосвязь серверных приложений и внешних сервисов, а также сделать предположения об архитектуре серверной части, – пояснил Алмаз Хабибуллин. – Кроме того, API позволит оценить применяемые подходы к обеспечению безопасности и следованию лучшим практикам в этом вопросе и провести первоначальное тестирование, определив соответствие заявленной и реальной функциональности продукта».
Все перечисленные выше моменты могут сильно сказаться на результате технологической оценки продукта и его финальной стоимости. Поэтому чем более зрело и продуманно выглядит проект с точки зрения построения API, тем выше вероятность получения высокой оценки, утверждает эксперт.
«Наиболее общая рекомендация при реализации API: регулярно сверяться с лучшими практиками, советоваться с коллегами не только в команде, но и в сообществе. При наличии достаточного опыта технического лидера или архитектора проекта сделать это можно еще до написания первых строк кода, применяя подход API first», – отмечает Алмаз Хабибуллин.
Что в API тебе моем?
При столь заблаговременной подготовке к технологическому аудиту важно, разумеется, видеть конечную цель: осознавать, какие именно нюансы окажутся при проверке работы API под пристальным вниманием.
«Прежде всего, аудиторы будут смотреть на правильность и работоспособность описанных в документации методов. Вторым этапом станет оценка модели зрелости REST: ясное разделение ответственности между ресурсами, корректное применение HTTP методов и заголовков, применение HATEOAS. Далее последует проверка полноты документации, описанной в ней реакции на пограничные, ошибочные, критические, нагруженные случаи, а также наличие документации описывающей, как именно использовать API. API бывают достаточно сложными, поэтому лучше приводить примеры и диаграммы их использования, – уточнил Ринат Хабибуллин. – В сфере внимания окажутся также наличие современных подходов к обеспечению безопасности и особенности их применения».
Кроме того, API иногда может раскрыть дополнительную информацию о связности с внешними сервисами, применяемой архитектуре (монолит, микросервисы, гибрид), развернутой инфраструктуре.
Ожидания VS реальность
Вернемся ненадолго к теме оценки соответствия заявленной и реальной функциональности продукта, которая также будет во главе угла при проведении технологического аудита. Как уже упоминалось выше, API может способствовать проведению сравнения проекта с его реальным воплощением в программном продукте, поскольку API создает основу и руководство для тестирования, которое можно проводить вручную или при помощи автотестов.
«Логирование и мониторинг реальных запросов помогает выявлять проблемы еще до того, как о них сообщил пользователь. Однако большая часть пользователей зачастую промолчит. Существуют учебные материалы и инструменты, которые описывают подходы к развитию так называемого Continuous API в цикле: проектирование – разработка – тестирование – эксплуатация – наблюдение. Каждый для своего проекта выбирает инструменты самостоятельно. В момент или в ходе очередной итерации разработки в цикле Continuous API понадобится актуализация проекта API с его реальным воплощением в develop, staging или production среде. Это позволит архитекторам API получить обратную связь, выявить ошибки, несоответствия проекта и реализации. Тестирование, логирование, мониторинг помогают устранить несоответствия на ранних этапах, уменьшая стоимость разработки», – обозначил Алмаз Хабибуллин.
Оценка результатов технологического аудита API будет выше при наличии внедренных инструментов тестирования, логирования и мониторинга. Степень, глубина и продуманность интеграций этих инструментов также напрямую скажутся на результатах оценки аудита.
В чем польза аудиторам?
И это еще не все: создание хорошо документированного API сильно облегчает и ускоряет технологический аудит, позволяет снять множество базовых вопросов, а также отразить уровень развития продукта.
«В зависимости от целей аудита – выход на биржу, очередной раунд инвестиций, слияние или поглощение – API может рассказать о широте реализованного функционала, а также о сложности интеграции API в полном или частичном виде», — заметил Ринат Хабибуллин.
При реализации API нужно помнить, что отрасль не стоит на месте. Регулярно сверяться с лучшими практиками при построении API – это не просто стандартная рекомендация, а необходимость. Создаются новые подходы, позволяющие проектировать API в формате Open API, который можно выгрузить, например, из Swagger существующего проекта. Совершенствуются способы формирования документации описывающей как именно использовать API. На рынке уже появляются инструменты, позволяющие спроектировать и отобразить архитектуру продукта, чтобы быть готовым к технологическому аудиту, и инструменты для сопоставления полей между моделями данных, чтобы было проще объяснять разработчикам, как связать данные между собой. Корректируется функционал в области поддержки брокеров сообщений и в сфере создания общих правил обработки запросов и ответов от клиентов – здесь тоже есть наши персональные наработки. И, что немаловажно, все перечисленные компоненты могут быть взаимосвязаны между собой и могут переиспользоваться, что значительно облегчает труд проектирования API.