Стоит прочитать: обзор книги Меджуи Мехди «Непрерывное развитие API. Правильные решения в изменчивом технологическом ландшафте»

Максим Васючков

ведущий инженер-программист «Контура»

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

Комитет по API

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

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

API as a Product

API — это продукт. Помимо того, что он упрощает распространение кода, он ещё несет бизнес ценность. Во-первых, его наличие способствует более глубокому проникновению наших продуктов в жизнь пользователей. Вы же получаете уведомления от Moira в Telegram или Slack? ? Во-вторых, API сам по себе имеет ценность и его можно продавать.

Бизнес цели, KPI, маркетинг и продажи. Все это нужно успешному API. У API есть пользователи — другие разработчики, для них важен позитивный опыт взаимодействия с сервисом. Поэтому дизайн, тех. поддержка и документация очень важны, иначе будет тяжело привлечь клиентов.

Всё это остается верным, даже когда API создается для внутреннего использования.

Столпы API

Авторы выделяют 10 «столпов API» — аспектов, которым необходимо уделять внимание при разработке, чтобы сделать успешный продукт.

Стратегия

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

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

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

Дизайн

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

API тоже может создавать вау-эффект. Представьте, что от знакомства с контрактом API до простейшей интеграции вы затратили 5 минут, круто же? )

Точно так же, как при проектировании UI, при проектировании API стоит стремиться сократить количество необходимых действий разработчика и сделать их интуитивно понятными, чтобы улучшить опыт использования.

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

Документация

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

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

Разработка

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

Тестирование

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

Развертывание

Чтобы использовать API, его нужно где-то разместить. Скорее всего, для отказоустойчивости запускается несколько реплик. Необходимо обеспечить их доступность и однообразное поведение. Вдобавок, API может зависеть от других сервисов — сложность управления релизами увеличивается.

Безопасность

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

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

Публикуя API, необходимо обеспечить безопасность пользователей и бизнеса.

Мониторинг

Чтобы успешно управлять API, нужно понимать его состояние и быстро реагировать на проблемы. Это поможет находить узкие места, подстраиваться под поведение пользователей и определять направления развития.

Обнаружение

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

Управление изменениями

API, как и другие продукты, должен развиваться. Нужно учитывать сколько стоит разработка и внедрение изменений, помогут ли они достичь целей. Вдобавок, неаккуратные изменения могут сломать поведение приложения, от которого зависят его пользователи — можно потерять больше, чем приобретём.

Итог

Помните, API — это продукт. Для его успеха недостаточно написать код, необходимо уделить внимание и другим аспектам. Разобраться в вопросах его создания и развития поможет книга «Непрерывное развитие API. Правильные решения в изменчивом технологическом ландшафте». Если есть возможность прочитать в оригинале, читайте в оригинале.