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

Kate

Administrator
Команда форума

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

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

Книга учит управлять разработкой и развитием 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 — это интерфейс. Интерфейс должен быть простым, понятным и удобным, он должен помогать решать задачи пользователей.
https://tproger.ru/articles/web-api/
API тоже может создавать вау-эффект. Представьте, что от знакомства с контрактом API до простейшей интеграции вы затратили 5 минут, круто же? )

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

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

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

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

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

Разработка​

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

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

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

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

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

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

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

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

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

Мониторинг​

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

Обнаружение​

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

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

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

Итог​

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

Источник статьи: https://tproger.ru/books/stoit-proc...ja-v-izmenchivom-tehnologicheskom-landshafte/
 
Сверху