Мышление платформы в управлении продуктами API

Ни для кого не секрет, что пандемия значительно усилила необходимость для организаций придерживаться цифровой стратегии. Цифровые преобразования, которые были лишены приоритета в пользу других организационных целей, в одночасье сместились на передний план с беспрецедентной срочностью. Согласно глобальному опросу руководителей McKinsey 2020 года, компании ускорили темпы оцифровки внутренних операций и расширения портфелей цифровых продуктов на несколько лет, несмотря на серьезные проблемы, связанные с COVID-19.

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

Делать больше с меньшими затратами

Еще до прошлого беспрецедентного года ценность API для организаций была хорошо задокументирована, и экономика API процветала в течение некоторого времени. Чтобы понять современный ландшафт интеграций, полезно изучить истоки философии Best of Breed (BoB). До 1990-х годов поставщики программного обеспечения продавали комплексные решения для планирования ресурсов предприятия (ERP), которые пытались решить широкий спектр организационных задач. Эти наборы все чаще стали рассматриваться как громоздкие и непрактичные, поскольку они не учитывали случаи использования, характерные для конкретной организации. В результате поставщики начали создавать более целенаправленные инструменты, которые решали проблемы в одной функциональной области, вместо более крупных наборов, которые пытались сделать все для всех. Предприятия приветствовали идею выбора из множества более мелких, более специализированных инструментов и начали собирать наборы индивидуальных решений, которые лучше всего соответствовали их конкретным потребностям.

Соединение точек

По мере того как подход BoB набирал обороты, интеграция стала важной частью продуктовых стратегий. Инструмент, который отлично подходил для решения проблем в одной области бизнеса, должен был хорошо интегрироваться с другими продуктами BoB, которые, вероятно, будут использоваться вместе с ним. Рассмотрим HubSpot, программное обеспечение для продаж и CRM, которое используется организациями для отслеживания и оптимизации каналов продаж и отношений с клиентами. HubSpot легко интегрируется с другим программным обеспечением BoB, таким как DocuSign (цифровые подписи), Twilio (уведомления по электронной почте/SMS) и Zendesk (поддержка клиентов), не требуя дополнительной разработки со стороны инженерных групп заказчика.

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

Предложение платформы

Однако истинная ценность интеграций выходит за рамки их способности координировать разрозненные инструменты и системы. В лучшем случае API — это коллективный механизм превращения продуктов в платформы. Продукты, по определению, являются инструментами, имеющими конкретное применение; отсюда «приложения». Они ограничены в своих возможностях создавать несколько ценностных предложений и, как следствие, несколько потоков доходов. Платформы, с другой стороны, добавляют ценность другим способом: предоставляя уровень инфраструктуры, на котором можно создавать многочисленные продукты.

API-интерфейсы открывают новые бизнес-каналы, извлекая выгоду из опыта третьих сторон, которые их используют. Разработчики-потребители могут разработать приложение для недвижимости, которое использует API-интерфейсы Google Maps Places, чтобы помочь пользователям найти дом, или они могут использовать API-интерфейсы Skyscanner для полетов и API-интерфейсы Expedia для отелей, чтобы создать сайт экотуризма, специализирующийся на поездках в определенное место. Эти разработчики и внешние партнеры получают выгоду, получая доступ к существующим данным и услугам, которые они могут адаптировать для своего бизнеса, а владельцы API, такие как Expedia, расширяют охват и монетизируют возможности, которых не было бы, если бы они продолжали, скажем, перечислять отели только в своем продукте.

Модульность

Для руководителей продуктов разработка успешной стратегии API требует перехода от мышления к продукту к мышлению о платформе. Это означает создание продуктов в модульной, открытой форме, которая позволяет рекомбинировать их функциональность и отдает предпочтение гибкости для разработчиков-потребителей. Подумайте о стеллажных системах ИКЕА, которые покупатели могут приобретать, собирать и настраивать различными способами для удовлетворения самых разных потребностей. Хорошие менеджеры продуктов API видят API такими, какие они есть: инструментами для масштабирования бизнеса и развития ценных партнерских отношений. Признание этого потенциала означает внедрение передового опыта для обеспечения внедрения.

В восторге от разработчиков

Если и есть фундамент надежной стратегии API, то это опыт разработчиков (DX). Для интеграций API «клиентские» менеджеры по продуктам должны радовать разработчиков-потребителей. Это пользователи, которые в конечном итоге звонят/интегрируются с API, потенциальные партнеры, которые могут помочь реализовать концепцию «продукт-платформа». Обозначение их опыта как «DX» вместо «UX» подтверждает, что они не являются типичными конечными пользователями — они значительно более технически подкованы. Чтобы сопереживать им, важно понимать их конкретные потребности и ожидания.

Лучшие практики

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

Согласованные соглашения об именах и конечных точках

Установление согласованных соглашений об именах для конечных точек API, которые четко определяют характер и цель API, устраняют двусмысленность и способствуют положительному и предсказуемому DX. Лучше всего выбрать общий базовый URL-адрес для всех API и структуру конечного URL-адреса, избегая жаргона и сокращений. Nordic APIs предлагает полезный список советов по именованию конечных точек.

Подробные структуры реагирования на успех и отказ

Разработчики хотят и ожидают знакомые объекты данных и коды состояния для ответов об успехе и неудаче. Это означает код состояния 2xx для успешных сценариев, код 4xx для сбоев на стороне клиента и код 5xx для ошибок на стороне сервера. Тем не менее, специфика является ключевым. Вызов API «отправить электронное письмо», который просто возвращает ответ 4xx без дополнительной информации, усложняет работу разработчика, поскольку он просто подтверждает, что ошибка была в клиентском запросе, не предоставляя дополнительной информации о том, что именно пошло не так.

 { "status": 400, "message": "incorrect request" }

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

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

Для оптимального DX структуры ответов и ключи, сообщающие о состоянии, должны быть согласованы между API. Например, поле кода ошибки в приведенном выше примере всегда должно называться «кодом» в каждом API, а не «кодом» в некоторых API и «кодом ошибки» в других.

Настраиваемые ограничения скорости

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

Чтобы наилучшим образом определить соответствующие ограничения скорости, полезно сначала сгруппировать API-интерфейсы в значимые категории в соответствии с частотой и объемом, с которым они вызываются. Например, API-интерфейсы, которые настраивают первичные данные клиента (создание профиля/учетной записи), вызываются реже и могут обрабатывать более низкие ограничения скорости, в то время как API-интерфейсы транзакций («создание заказа», «отправка электронной почты») вызываются чаще, требуя более высоких ограничений скорости. Создание категорий или уровней для различных вариантов использования делает API более надежными и масштабируемыми. Пример четко определенных ограничений скорости см. в документации API Slack.

Полная документация

Документация служит руководством пользователя для API. Он четко объясняет разработчикам, что делает API, как его использовать и чего от него ожидать. Хорошая документация написана ясным, доступным языком, детализирована и интерактивна, содержит множество демонстраций и фрагментов кода, упрощающих интеграцию. Таким образом, он облегчает адаптацию и быстрое время до первого Hello World (TTFHW), важный показатель, который показывает, насколько быстро разработчик может успешно вызвать свой первый API.

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

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

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

Собираем все вместе

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