mirror of
https://github.com/twirl/The-API-Book.git
synced 2025-03-17 20:42:26 +02:00
Section III finished
This commit is contained in:
Sergey Konstantinov
parent
6883c6b84e
commit
1d126e352c
@ -2,17 +2,17 @@
|
||||
|
||||
Когда мы говорим об API как о продукте, необходимо чётко зафиксировать два важных тезиса.
|
||||
|
||||
1. API — это *полноценный продукт*, как и другое ПО. Вы «продаёте» его точно так же, и к нему полностью применимы принципы маркетинга. Весьма сомнительно, что вы сможете качественно продвигать API, не изучив потребности аудитории, спрос и предложение, рынок, конкурентов, потребителей — короче говоря, не проведя всестороннее маркетинговое исследование.
|
||||
1. API — это *полноценный продукт*, как и другое ПО. Вы «продаёте» его точно так же, и к нему полностью применимы принципы управления продуктом. Весьма сомнительно, что вы сможете качественно развивать API, не изучив потребности аудитории, спрос и предложение, рынок и конкурентов.
|
||||
|
||||
2. API — это *очень специфический продукт*. Вы продаёте возможность некоторые действия выполнять автомизированно посредством написания кода, и этот факт накладывает большие ограничения на управление продуктом.
|
||||
|
||||
Для того, чтобы успешно распространять API, необходимо уметь отвечать именно на этот вопрос: почему ваши потребители предпочтут выполнять те или иные действия *программно*. Вопрос этот не праздный, поскольку, по опыту автора настоящей книги, именно отсутствие у руководителей продукта и маркетологов экспертизы в области работы с API и есть самая большая проблема развития продукта API. Конечный пользователь взаимодействует с каким-то решением, которое поверх вашего API написали разработчики, работающие на какой-то сторонний бизнес (причём иногда в цепочке между вами и конечным пользователем находится ещё и более одного разработчика).
|
||||
|
||||
С этой точки зрения целевая аудитория API — это некоторая пирамида, подобная пирамиде Маслоу:
|
||||
* вершиной пирамиды являются разработчики: именно они непосредственно работают с API, и они выбирают, какой из конкурирующих API им подходит;
|
||||
* средний ярус пирамиды — бизнес-заказчики; они строят продукт, опираясь на разработчиков;
|
||||
* наконец, основание пирамиды — пользователи; в подавляющем большинстве случаев они не выбирают *технологию*, она их не интересует; пользователь выбирает из тех вариантов решения своих задач, которые предложит бизнес.
|
||||
Для того, чтобы успешно развивать API, необходимо уметь отвечать именно на этот вопрос: почему ваши потребители предпочтут выполнять те или иные действия *программно*. Вопрос этот не праздный, поскольку, по опыту автора настоящей книги, именно отсутствие у руководителей продукта и маркетологов экспертизы в области работы с API и есть самая большая проблема развития API.
|
||||
|
||||
Конечный пользователь взаимодействует не с вашим API напрямую, а посредством каких-то решений, которые поверх API написали разработчики в интересах какого-то стороннего бизнеса (причём иногда в цепочке между вами и конечным пользователем находится ещё и более одного разработчика). С этой точки зрения целевая аудитория API — это некоторая пирамида, напоминающая пирамиду Маслоу:
|
||||
* основание пирамиды — это пользователи; они ищут удовлетворение каких-то своих потребностей и не думают о технологиях;
|
||||
* средний ярус пирамиды — бизнес-заказчики; соотнеся потребности пользователей с техническими возможностями, озвученными разработчиками, бизнес строит продукты;
|
||||
* вершиной же пирамиды являются разработчики: именно они непосредственно работают с API, и они решают, какой из конкурирующих API им выбрать.
|
||||
|
||||
Непосредственный вывод из этой модели звучит так: в достоинствах вашего API в первую очередь необходимо убедить разработчиков; они, в свою очередь, примут решение о выборе технологии, ну а бизнес оттранслирует концепцию пользователям. Если руководителями продукта API являются бывшие или действующие разработчики, они зачастую склонны оценивать конкуренцию на рынке API именно в этом аспекте, и направлять основные усилия по продвижению продукта именно на аудиторию программистов.
|
||||
|
||||
«Постойте!» — воскликнет здесь внимательный читатель. Но ведь дела здесь обстоят с точностью до наборот:
|
||||
@ -22,6 +22,6 @@
|
||||
|
||||
Получается, что на вершине пирамиды, таким образом, находится конечный пользователь: это его нам нужно убедить, что он хочет не какую попало кружку кофе, а именно приготовленную через наш API (и отдельный вопрос, как же мы будем доносить информацию о том, что за API работает под капотом, и почему пользователь должен своими деньгами проголосовать именно за наш API!); тогда бизнес поставит разработчику задачу интегрировать наш API, ну а разработчик уже никуда не денется и напишет код (что, кстати, означает, что вкладываться в читабельность и консистентность API не так уж и обязательно).
|
||||
|
||||
Истина, разумеется, лежит где-то посередине. В каких-то предметных областях и на каких-то рынках все решения принимаются разработчиками (например, какой фреймворк выбрать); в других областях и рынках последнее слово остаётся за бизнес-заказчиком и конечным пользователем. К тому же, многое зависит от конкурентной ситуации; новому игроку войти на рынок, например, мобильных операционных систем очень дорого и малоперспективно.
|
||||
Истина, разумеется, лежит где-то посередине. В каких-то предметных областях и на каких-то рынках все решения принимаются разработчиками (например, какой фреймворк выбрать); в других областях и рынках последнее слово остаётся за бизнес-заказчиком и конечным пользователем. К тому же, многое зависит от конкурентной ситуации — если вход на рынок фронтенд-разработки с новым фреймворком не сталкивается ни с каким противодействием, то разработка, например, новой мобильной операционной системы требует многомиллионных расходов на продвижение и стратегические партнерства.
|
||||
|
||||
Здесь и далее мы будем описывать некоторый «усреднённый» случай, в котором все три яруса пирамиды важны: и пользователи (которые выбирают качественный продукт), и бизнес (которому важны гарантии качества и стоимость разработки), и разработчики (которых интересует удобство работы с API и его функциональность).
|
||||
Здесь и далее мы будем описывать некоторый «усреднённый» случай, в котором все три яруса нашей двойной пирамиды важны: и пользователи (которые выбирают подходящий продукт), и бизнес (которому важны гарантии качества и стоимость разработки), и разработчики (которых интересует удобство работы с API и его функциональность).
|
||||
@ -1,4 +0,0 @@
|
||||
### Востребованность API
|
||||
|
||||
Описанная выше фрагментация целевой аудитории API, триада «разработчики — бизнес — конечные пользователи», делает управление продуктом API весьма нетривиальной проблемой. Да, базовый принцип — выяснить потребности аудитории и удовлетворить их — всё тот же; только аудиторий у вашего продукта три, причём их интересы далеко не всегда коррелируют. Из потребности конечного пользователя в качественном и недорогом кофе отнюдь не следует потребность бизнеса в API для работы с кофе-машинами.
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
### Бизнес-модели API
|
||||
|
||||
Как мы неоднократно упоминали в предыдущих разделах, предоставление некоторой функциональности посредством программируемых интерфесов — достаточно дорогое удовольствие. Для создания и поддержания API требуется соответствующий отдел разработки, и публикация API представляет собой принятие определённых обязательств по поддержке, от которых нельзя так просто отказаться. Возникает логичный вопрос, зачем и почему вообще предоставлять функциональность именно в виде API, т.е. продукта для программистов, вместо того, чтобы ограничиться продуктом для конечного потребителя. Рассмотрим здесь различные ситуации, в которых наличие API приносит выгоду компании, а также соответствующие модели монетизации, прямой и косвенной. [В квадратных скобках будем приводить примеры подобных моделей применительно к нашему учебному примеру с API кофе-машин.]
|
||||
Прежде, чем переходить непосредственно к принципам продуктового управления API, позволим себе заострить внимание читателя на вопросе, каким образом наличие API как продукта приносит пользу компании, а также соответствующие модели монетизации, прямой и косвенной. Вопрос этот, как мы покажем в следующих главах, далеко не праздный, так как напрямую влияет на KPI API и принятие решений. [В квадратных скобках будем приводить примеры подобных моделей применительно к нашему учебному примеру с API кофе-машин.]
|
||||
|
||||
##### Разработчик = конечный пользователь
|
||||
|
||||
Самая простая и понятная ситуация — в том случае, если разработчики и есть конечные пользователи. В первую очередь здесь речь идёт о всевозможных инструментах для программиста: API языков программирования, фреймворков, операционных систем, библиотек компонентов, игровых движков и так далее, — иными словами, интерфейсы общего назначения. [В нашем кофейном примере это означает следующее: мы разработали библиотеку для заказа кофе, возможно, с визуальными компонентами, и теперь продаём всем желающим-владельцам сети кофе-машин, чтобы облегчить им разработку собственного приложения.] В этом случае ответ на вопрос «зачем предоставлять программный интерфейс» самоочевиден.
|
||||
Самая простая и понятная ситуация — в том случае, если разработчики и есть конечные пользователи. В первую очередь здесь речь идёт о всевозможных инструментах для программиста: API языков программирования, фреймворков, операционных систем, библиотек компонентов, игровых движков и так далее, — иными словами, об интерфейсах общего назначения. [В нашем кофейном примере это означает следующее: мы разработали библиотеку для заказа кофе, возможно, с визуальными компонентами, и теперь продаём всем желающим-владельцам сети кофе-машин, чтобы облегчить им разработку собственного приложения.] В этом случае ответ на вопрос «зачем предоставлять программный интерфейс» самоочевиден.
|
||||
|
||||
Видов монетизации такого API существует множество — по сути, речь идёт о моделях монетизации ПО для разработчиков как таковом.
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
|
||||
##### API = основной и/или единственный способ доступа к сервису
|
||||
|
||||
Этот случай примыкает к предыдущему в том смысле, что потребителем API является разработчик, а не конечный пользователь — с той разницей, что продуктом является не сам API, а сервис, доступ к которому он предоставляет. Чистый пример — это API различных облачных платформ, например, Amazon AWS или Uber Freight API. Да, какая-то работа с платформой возможна и через UI, но без API такие сервисы практически бесполезны. [В нашем кофейном примере — если мы являемся оператором сети кофе-машин, и предоставляем к ним доступ через API.]
|
||||
Этот случай примыкает к предыдущему в том смысле, что потребителем API является разработчик, а не конечный пользователь — с той разницей, что продуктом является не сам API, а сервис, доступ к которому он предоставляет. Чистый пример — это API различных облачных платформ, например, Amazon AWS или Uber Freight API. Да, какая-то работа с платформой возможна и через UI, но без API такие сервисы практически бесполезны. [В нашем кофейном примере — если мы являемся оператором сети «облачных» кофе-машин и доставки кофе дронами, и предоставляем к ним доступ только через API.]
|
||||
|
||||
Как правило, тарифицируется в этом случае использование самого сервиса, а не API как такового. Часто, однако, тарифы исчисляются именно по сущностям API, т.е. тарифицируется количество вызовов методов.
|
||||
|
||||
@ -39,20 +39,20 @@
|
||||
|
||||
Доступ к API в этом случае может быть безусловно платным, хотя чаще встречаются смешанные модели монетизации: API предоставляется бесплатно до достижения какого-то лимита либо при соблюдении определённых условий (например, для некоммерческих проектов). В отдельных случаях API предоставляется бесплатно с минимальными ограничениями с целью популяризации определённой платформы (например, Apple Maps).
|
||||
|
||||
Отдельно здесь следует отметить B2B-сервисы. Так как провайдеру сервиса выгодно дать клиенту как можно более разнообразные возможности, а клиенту, в свою очередь, часто требуется максимально гибко использовать имеющуюся функциональность, часто предоставление API — оптимальный выход для обеих сторон. Крупным компаниям, располагающим своими отделами разработки, чаще необходимо запрограммировать свои бизнес-процессы через API и интегрировать их со своими внутренними системами.
|
||||
Отдельно здесь следует отметить B2B-сервисы. Так как провайдеру сервиса выгодно дать клиенту как можно более разнообразные возможности, а клиенту, в свою очередь, часто требуется максимально гибко использовать имеющуюся функциональность, часто предоставление API — оптимальный выход для обеих сторон. Крупным компаниям, располагающим своими отделами разработки, чаще необходимо запрограммировать свои бизнес-процессы через API и интегрировать их со своими внутренними системами. Часто таким B2B-сервисом выступает сама компания — разработчик API, если собственные сервисы компании строятся поверх API же, а внешний API существует в дополнение к внутреннему (или вовсе «на сдачу»).
|
||||
|
||||
##### API как площадка для рекламы
|
||||
|
||||
В основном речь здесь идёт о разного рода виджетах и поисковиках: чтобы размещать какую-то рекламу, необходимо иметь прямой доступ к конечному пользователю. Наиболее распространённые API такого типа — это собственно API рекламных сетей, однако встречаются и комбинированные подходы, когда вместе с некоторым API, например, поисковым, «в нагрузку» идёт показ рекламы. [В нашем кофейном примере — если наша функция поиска предложений напитков начнёт каким-то образом выделять на странице результатов оплаченные показы.]
|
||||
|
||||
##### API как самореклама
|
||||
##### API как самореклама и самопиар
|
||||
|
||||
Если никакой — ни прямой, ни косвенной — монетизации API не имеет, он всё ещё может приносить доход, развивая знание о компании через брендирование — отображение логотипов и других узнаваемых элементов при работе пользователя с API, нативное (если визуальные интерфейсы отрисовываются непосредственно самим API) или договорное — потребители API обязаны по контракту размещать определённые элементы брендирования там, где используется фунциональность API или предоставленные через него данные. Целью компании-разработчика API в этом случае является или привлечение аудитории на свои основные сервисы, либо продвижение своего бренда в целом. [В случае нашего кофейного API — представим, что мы предоставляем некоторый совершенно иной полезный сервис, допустим, продаём автомобильные шины, а через предоставление API кофе-машин пытается увеличить узнаваемость и заработать себе репутацию технологической компании.]
|
||||
|
||||
В этом случае возможны вариации относительно целевой аудитории саморекламы:
|
||||
* вы можете работать на узнаваемость бренда среди конечных пользователей (размещением своих логотипов и ссылок на сайтах и в приложениях партнёров, использующих API), и даже строить сам бренд таким образом [например, если наш кофейный API будет предоставлять рейтинги кофеен, и мы будем работать на то, чтобы потребитель сам требовал от кофеен указывать рейтинг по версии нашего сервиса];
|
||||
* вы можете работать на распространение знания о себе среди бизнес-аудитории [например, чтобы партнёры, размещающие у себя виджет заказа кофе, заодно и изучили каталог ваших шин];
|
||||
* наконец, вы можете распространять API только и исключительно ради того, чтобы заработать себе репутацию среди разработчиков — ради информирования о других ваших продуктов или ради улучшения вашего имиджа как работодателя для ИТ-специалистов.
|
||||
* наконец, вы можете распространять API только и исключительно ради того, чтобы заработать себе репутацию среди разработчиков — ради информирования о других ваших продуктов или ради улучшения вашего имиджа как работодателя для ИТ-специалистов (эту деятельность иногда называют словом «технопиар»).
|
||||
|
||||
Дополнительно в этом разделе можно говорить о формировании комьюнити, т.е. сообщества пользователей или разработчиков, лояльных к продукту. Выгоды от существования таких комьюнити бывают довольно существенны: это и снижение расходов на техническую поддержку, и удобный канал информирования о новых сервисах и релизах, и возможность получить бета-тестеров новых продуктов.
|
||||
|
||||
@ -72,7 +72,7 @@
|
||||
|
||||
В последние годы набирает силу тенденция предоставлять некоторую функциональность в виде API (т.е. продукта для разработчиков) там, где теоретически можно было бы предоставить сервис напрямую конечным пользователям. Этот подход известен как «API-first» и отражает нарастающую специализацию IT-сферы в целом: разработка API выделяется в отдельную компетенцию, которую бизнес готов отдавать сторонним компаниям вместо того, чтобы нанимать штат «универсальных солдат», которые могут разработать и приложение для конечного пользователя, и внутренний API для него. Тем не менее, пока этот подход не является универсально общепринятым, следует помнить о факторах принятия решений, когда можно запускать сервис в формате API-first.
|
||||
|
||||
1. Целевой рынок должен быть достаточно «прогрет» — на нём уже должны действовать компании, обладающие достаточным ресурсом для разработки сервисов поверх вашего API, и готовых, к тому же, оплачивать его использование (если только вашей целью не является самореклама или улучшение климата);
|
||||
1. Целевой рынок должен быть достаточно «прогрет» — на нём уже должны действовать компании, обладающие достаточным ресурсом для разработки сервисов поверх вашего API, и готовых, к тому же, оплачивать его использование (если только вашей целью не является самореклама или терраформирование);
|
||||
|
||||
2. Качество сервиса не должно страдать от того, что он предоставляется через API;
|
||||
|
||||
@ -0,0 +1,28 @@
|
||||
### Формирование продуктового видения
|
||||
|
||||
Описанная выше фрагментация целевой аудитории API, триада «разработчики — бизнес — конечные пользователи», делает управление продуктом API весьма нетривиальной проблемой. Да, базовый принцип — выяснить потребности аудитории и удовлетворить их — всё тот же; только аудиторий у вашего продукта три, причём их интересы далеко не всегда коррелируют. Из потребности конечного пользователя в качественном и недорогом кофе отнюдь не следует потребность бизнеса в API для работы с кофе-машинами.
|
||||
|
||||
В общем случае продуктовое видение будущего API тоже должно включать в себя те же три звена:
|
||||
* представление об идеальном решении проблем конечного пользователя;
|
||||
* предположения о том, каким образом бизнес подошёл бы к решению этих проблем, располагая техническими инструментами;
|
||||
* понимание доступного спектра технических решений и их применимости.
|
||||
|
||||
На разных рынках и в разных ситуациях «вес» каждой ступени различен. Если вы произодите API-first продукт для разработчиков (без визуальной составляющей), то вы вполне можете обойтись без анализа проблем конечных пользователей; и наоборот, если вы предоставляете API к чрезвычайно ценной для пользователя функциональности в условиях, близких к монопольным, — вам в общем-то всё равно, насколько разработчикам нравится ваша архитектура и удобно ли им работать с вашими интерфейсами, выбора у них все равно нет.
|
||||
|
||||
В большинстве же случаев мы имеем дело с некоторой двухуровневой эвристикой, которая идёт или от технических возможностей, или от бизнес-потребностей:
|
||||
* либо, исходя из вашего понимания спектра доступных технических решений, вы пытаетесь сформировать понимание, как вы могли бы помочь бизнесу (первый шаг эвристики), а уже из него — общее представление о том, как ваш API будет помогать конечным пользователям (второй шаг эвристики);
|
||||
* либо, исходя из вашего понимания проблем, стоящих перед бизнес партнёрами, вы можете сделать «шаг вправо», обрисовав будущую функциональность для конечных пользователей, и «шаг влево», прикинув возможные технические решения.
|
||||
|
||||
Из эвристичности обоих подходов неизбежно следует и неопределённость продуктового видения API; в большинстве случаев это нормально: если бы вы могли иметь полное и чёткое представление о том, какие продукты для пользователей можно разработать поверх вашего API, вы могли бы разработать их сами, опустив промежуточное звено в виде партнёров. Здесь также важно и то, что многие API проходят стадию «терраформирования» (см. предыдущую главу), то есть «подготавливают почву» для новых рынков и видов сервисов — таким образом, ваше идеализированное представление о светлом будущем, когда доставка готового кофе дронами будет нормой жизни, будет постепенно детализироваться по мере появления на этом рынке новых компаний, предоставляющих новые виды услуг. (Что, в свою очередь, отразится и на моделях монетизации: по мере детализации облика грядущего вы будете переходить от всё более абстрактных KPI и теоретических выгод наличия API ко всё более конкретным.)
|
||||
|
||||
Ту же неопределённость следует иметь в виду и при проведении интервью и сборе обратной связи. Программисты будут, в основном, сообщать вам о своих проблемах, возникающих при разработке сервиса — редко о проблемах бизнеса; бизнесу, в свою очередь, мало дела до неудобств разработчиков. И те, и другие обладают при этом каким-то представлением о проблемах пользователя, но зачастую это представление сильно ограничено сегментом рынка, в котором оперирует партнёр.
|
||||
|
||||
#### Проверка продуктовых гипотез
|
||||
|
||||
Помимо общих сложностей с формированием продуктового видения API есть и более частные сложности с проверкой продуктовых гипотез. «Святой грааль» управления продуктом — создание максимально недорогого с точки зрения затраченных ресурсов minimal viable product (MVP) — обычно недоступен для менеджера API. Дело в том, что вы не можете так просто *проверить* MVP, даже если вам удалось его разработать: для проверки MVP API партнёры должны *написать код* (читай — вложить свои деньги); если по итогам этого эксперимента будет принято решение о бесперспективности продукта, эти деньги окажутся потрачены впустую. Разумеется, партнёры к подобного рода предложениям относятся с некоторым скептицизмом. Таким образом «дешёвый» MVP включает в себя либо компенсацию расходов партнёрам, либо затраты на разработку референсного приложения (т.е. в дополнение к MVP API разрабатывается сразу и MVP приложения, использующего этот API).
|
||||
|
||||
Частично эту проблему можно решить, если выпустить MVP от имени сторонней компании (например, в виде модуля с открытым кодом, опубликованного от лица разработчика). Однако тогда вы получите проблемы с собственно проверкой гипотезы, так как подобные модули рискуют быть просто оставленными без внимания.
|
||||
|
||||
Другой вариант проверки гипотез — это собственный сервис (или сервисы) компании-разработчика API, если такие есть. Внутренние заказчики обычно более лояльно относятся к трате ресурсов на проверку гипотез, и с ними легче договориться о сворачивании или замораживании MVP. Однако таким образом можно проверить далеко не всякую функциональность — а только то, на которую имеется хоть в каком-то приближении внутренний заказ.
|
||||
|
||||
Вообще, концепция ‘eat your own dogfood’ применительно к API означает, что у команды продукта есть какие-то свои тестовые приложения (т.н. ‘pet project’-ы) поверх API. Учитывая трудоёмкость разработки подобных приложений, имеет смысл поощрять их наличие, например, предоставлением бесплатных квот на API и вычислительные ресурсы членам команды.
|
||||
@ -1,8 +1,10 @@
|
||||
### Взаимодействие с разработчиками
|
||||
|
||||
Специфика аудтории API заключается в том, что:
|
||||
Как мы описали в предыдущих главах, управление продуктом API требует выстраивания отношений и с бизнес-партнёрами, и с разработчиками. (В идеале и с конечными пользователями, но эта опция разработчикам API крайне редко доступна.)
|
||||
|
||||
* разработчики — высокообразованные люди с практически-прикладным рациональным мышлением; как правило, выбор продукта ими осуществляется предельно рационально (это не исключает определённой вкусовщины в части выбора, скажем, языков программирования или вендоров программного обеспечения; однако *повлиять* на эти вкусы практически невозможно);
|
||||
Начнём с разработчиков. Специфика программистов как аудитории API заключается в том, что:
|
||||
|
||||
* разработчики — высокообразованные люди с практически-прикладным рациональным мышлением; как правило, выбор продукта ими осуществляется предельно рационально (это не исключает определённой вкусовщины в части выбора, скажем, языков программирования или вендоров программного обеспечения; однако *повлиять* на эти вкусы крайне сложно и обычно за пределами возможностей поставщика API);
|
||||
|
||||
* в частности, разработчики скептически относятся к громким рекламным заявлениям и готовы разбираться в том, насколько эти заявления соответствуют истине;
|
||||
|
||||
@ -18,15 +20,15 @@
|
||||
* профессиональных программистов, имеющих широкий опыт интеграции различного рода систем;
|
||||
* начинающих и полупрофессиональных разработчиков, для которых каждая такого рода интеграция является новой и неизведанной территорией.
|
||||
|
||||
Существует мнение, что угодить одновременно обеим аудиториям невозможно: первые ищут возможности глубокой кастомизации (поскольку работают в крупных ИТ-компаниях со сложившимся подходом к разработке), вторым необходим максимально заниженный порог входа. Мы с этим мнением склонны не согласиться по причинам, описанным в следующей главе.
|
||||
Существует мнение, что угодить одновременно обеим аудиториям невозможно: первые ищут возможности глубокой кастомизации (поскольку работают в крупных ИТ-компаниях со сложившимся подходом к разработке), вторым необходим максимально заниженный порог входа. Мы с этим мнением склонны не согласиться по причинам, описанным в главе «Линейка сервисов API».
|
||||
|
||||
В силу описанных выше причин (низкая роль инфлюэнсеров, критическое отношение к рекламным заявлениям) доносить информацию до разработчиков приходится через специфические каналы:
|
||||
* коллективные блоги (такие, например, как субреддит ‘programming’ или dev.to);
|
||||
* сайты вопросов и ответов (Quora, StackOverflow);
|
||||
* обучающие сервисы типа CodeAcademy или Udemy;
|
||||
* обучающие сервисы (CodeAcademy, Udemy и другие);
|
||||
* технические конференции и вебинары.
|
||||
|
||||
Во всех этих каналах прямая реклама вашего сервиса затруднена или невозможна вовсе. Вам необходимо генерировать какой-то ценный и/или интересный контент для улучшения знания о вашем API, и эта работа тоже ложится на ваших разработчиков: писать тексты, отвечать на вопросы, записывать обучающие семинары, выступать с докладами.
|
||||
Во всех этих каналах прямая реклама вашего сервиса затруднена или невозможна вовсе. (Точнее, конечно, вы можете купить баннерную рекламу, но мы выразим очень большие сомнения в том, что это поможет вам выстроить отношения с разработчиками.) Вам необходимо генерировать какой-то ценный и/или интересный контент для улучшения знания о вашем API, и эта работа тоже ложится на ваших разработчиков: писать тексты, отвечать на вопросы, записывать обучающие семинары, выступать с докладами.
|
||||
|
||||
Программисты любят делиться опытом, и с удовольствием будут заниматься всеми вышеперечисленными задачами (в рабочее время); однако хорошее выступление на конференции, не говоря уже об обучающем курсе, требует многих часов подготовки. По опыту автора настоящей книги две вещи критически важны для качественного технопиара:
|
||||
* поощрения, пусть даже номинальные — работа по продвижению должна как-то вознаграждаться;
|
||||
@ -34,4 +36,16 @@
|
||||
|
||||
Почти ничто не сделает вам худшей антирекламы, нежели плохо подготовленное выступление (см. выше — ошибки в вашей презентации непременно найдут) или плохо замаскированная реклама (по той же причине). Над текстами надо работать: следить за структурой, логикой и темпом повествования. И технический рассказ должен быть хорошо выстроен; по его окончании у слушателей должно сложиться чёткое понимание того, какую мысль им хотели донести (и хорошо бы эта мысль была как-то увязана с тем, что ваш API великолепно подходит для их нужд).
|
||||
|
||||
Отдельно следует упомянуть о «евангелистах»: так называют людей, обычно, обладающих определённым авторитетом в ИТ-сообществе, которые продвигают ту или иную технологию или компанию — то есть делают всё вышеперечеисленное (пишут в блоги, записывают курсы, выступают на конференциях) за вас (чаще всего будучи внештатными, а иногда и штатными сотрудниками компании). Евангелист, таким образом, разгружает команду от необходимости заниматься технопиаром. Мы же всё-таки склонны считать, что эту функцию лучше иметь внутри команды, поскольку прямое взаимодействие с разработчиками чрезвычайно полезно для понимая состояния продукта.
|
||||
Отдельно следует упомянуть о «евангелистах»: так называют людей, обычно, обладающих определённым авторитетом в ИТ-сообществе, которые продвигают ту или иную технологию или компанию — то есть делают всё вышеперечеисленное (пишут в блоги, записывают курсы, выступают на конференциях) за вас (чаще всего будучи внештатными, а иногда и штатными сотрудниками компании). Евангелист, таким образом, разгружает команду от необходимости заниматься технопиаром. Мы же всё-таки склонны считать, что эту функцию лучше иметь внутри команды, поскольку прямое взаимодействие с разработчиками чрезвычайно полезно для формирования продуктового видения.
|
||||
|
||||
#### Open Source
|
||||
|
||||
Важный вопрос, который рано или поздно встанет перед любым провайдером API — это выкладывание кода в Open Source. У этого действия есть как достоинства, так и недостатки:
|
||||
* вы повысите узнаваемость вашего бренда и приобретёте какое-то уважение в среде разработчиков;
|
||||
* если, конечно, ваш API достаточно хорошо написан и прокомментирован;
|
||||
* вы получите какой-то дополнительный фидбек, в идеальном случае даже pull request-ы от сторонних разработчиков;
|
||||
* а ещё вы получите какое-то количество обращений и комментариев, от бесполезных до откровенно провокационных, на которые нужно будет корректно отвечать;
|
||||
* открытый код повышает доверие разработчиков и их готовность развивать платформу и писать модули для неё;
|
||||
* открытый код также означает и повышенные риски, как с точки зрения безопасности, так и с точки зрения того, что недовольное комьюнити может создать форк вашего репозитория и породить конкурирующий API.
|
||||
|
||||
Наконец, просто подготовка к открытию кода API сама по себе может быть весьма затратна: во-первых, код надо «причесать», во-вторых, перейти на открытые же инструменты сборки и тестирования, убрав из кода все ссылки на проприетарные ресурсы. Решение здесь следует принимать максимально осторожно, взвесив все «за» и «против». Добавим, что многие компании пытаются снизить перечисленные выше риски, разделив API на две части, открытую и проприетарную, а также путём подбора специфической лицензии, которая не позволит нанести вред интересам компании через использование открытого кода (например, запрещая продавать hosted-решения или требуя обязательного раскрытия производного кода).
|
||||
@ -1,6 +1,6 @@
|
||||
### Линейка сервисов API
|
||||
|
||||
Первое правило управления продуктом API, которое любой достаточно крупный поставщик API довольно быстро для себя откроет, звучит так: нет смысла поставлять всего лишь один какой-то API; есть смысл говорить о наборе продуктов, причём в двух измерениях.
|
||||
Важное правило управления продуктом API, которое любой достаточно крупный поставщик API довольно быстро для себя откроет, звучит так: нет смысла поставлять всего лишь один какой-то API; есть смысл говорить о наборе продуктов, причём сразу в двух измерениях.
|
||||
|
||||
#### Горизонтальное разделение сервисов API
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
### KPI API
|
||||
|
||||
Как мы описали выше, существует большое количество различных моделей монетизации API, прямой и косвенной. Важной их особенностью является то, что, во-первых, большинство из них является частично или полностью бесплатными для партнёра, а, во-вторых, соотношение прямой и косвенной выгоды часто меняется в течение жизненного цикла API (что характерно для всех современных IT-стартапов; в этом смысле API не выделяется среди других программных продкетов). Возникает вопрос, каким же образом следует измерять успех API и какие цели ставить продуктовой команде.
|
||||
Как мы описали выше, существует большое количество различных моделей монетизации API, прямой и косвенной. Важной их особенностью является то, что, во-первых, большинство из них является частично или полностью бесплатными для партнёра, а, во-вторых, соотношение прямой и косвенной выгоды часто меняется в течение жизненного цикла API. Возникает вопрос, каким же образом следует измерять успех API и какие цели ставить продуктовой команде.
|
||||
|
||||
Разумеется, наиболее прямым измеримым показателем являются деньги: если ваш API имеет прямую монетизацию либо явно приводит пользователей на монетизируемый сервис, то остальная часть главы будет вам интересна разве что в рамках общего развития. Если же напрямую измерить вклад API в доходы компании не получается, придётся прибегать к иным, синтетическим, показателям.
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
|
||||
Однако чистые цифры количества пользователей и партнёров могут вводить в заблуждение, особенно в случае бесплатных инсталляций. Есть несколько факторов, искажающих статистику:
|
||||
|
||||
* сервисы в линейке API-продуктов, рассчитанные на простую интеграцию (см. соответствующий раздел) существенно искажают статистику количества партнёров в сравнении с конкурентами, если у них таких сервисов нет; зачастую на одну глубокую интеграцию приходятся десятки, если не сотни более простых; таким образом, подсчёт партнёров сдедует как минимум делить по видам интеграции;
|
||||
* сервисы в линейке API-продуктов, рассчитанные на простую интеграцию (см. предыдущую главу) существенно искажают статистику количества партнёров в сравнении с конкурентами, если у них таких сервисов нет; зачастую на одну глубокую интеграцию приходятся десятки, если не сотни более простых; таким образом, подсчёт партнёров сдедует как минимум делить по видам интеграции;
|
||||
|
||||
* партнёры склонны использовать API неоптимально:
|
||||
|
||||
@ -16,7 +16,7 @@
|
||||
* размещать виджеты глубоко в «подвале» или за спойлером;
|
||||
* инициализировать широкий набор модулей, но использовать только тривиальную функциональность;
|
||||
|
||||
* чем шире распространён ваш API, тем менее значим показатель количества уникальных пользователей, поскольку в какой-то момент проникновение API в сервисы, которыми пользуется целевая аудитория, приблизится к 100%; например, с сервисами Facebook или Google в виде счётчиков и виджетов средний пользователь Интернета встречается чуть ли не ежеминутно, и дневная аудитория этих API уже в принципе вырасти не может.
|
||||
* чем шире распространён ваш API, тем менее значим показатель количества уникальных пользователей, поскольку в какой-то момент проникновение API приблизится к 100%; например, с сервисами Facebook или Google в виде счётчиков и виджетов средний пользователь Интернета встречается чуть ли не ежеминутно, и дневная аудитория этих API уже в принципе вырасти не может.
|
||||
|
||||
Вышеперечисленные проблемы приводят нас к простому выводу: считать нужно не только сырые цифры количества уникальных пользотелей и партнёров, но и их вовлечённость, т.е. выделить целевые действия (например, количество поисков через платформу, показ определённых данных, события взаимодействия пользователя с виджетом и т.д.). В идеале эти целевые действия должны коррелировать с монетизацией:
|
||||
|
||||
@ -24,9 +24,15 @@
|
||||
* если API приводит пользователя на сайт материнского сервиса — считать переходы;
|
||||
* если API используется для сбора обратной связи и UGC — считать оставленные отзывы и исправления.
|
||||
|
||||
Наиболее непростая ситуация с KPI наблюдается, если API в первую очередь способ (техно)пиара и (техно)маркетинга. В этом случае наблюдается накопительный эффект: наращивание аудитории не конвертируется в пользу компании моментально. *Сначала* вы набираете большую лояльную аудиторию разработчиков, *потом* репутация вашей компании улучшается, и ещё более потом эта репутация начинает играть вам на руку при найме. *Сначала* логотип вашей компании появляется на сторонних сайтах и приложениях, *потом* top-of-mind знание бренда увеличится. Нет прямого способа отследить, как то или иное действие (например, релиз новой версии или проведение мероприятия) сказывается на целевых показателях. В этом случае приходится оперировать косвенными показателями — посещаемость ресурсов для разработчиков, количество упоминаний в тематических сообществах, помещаемость блогов и мероприятий и т.п.
|
||||
Довольно часто встречаются также такие KPI как использование той или иной функциональности API (в том числе для приоритизации планов разработки). По сути это те же целевые действия, но только совершаемые разработчиком, а не пользователем. Для библиотек, особенно клиентских, сбор этой информации бывает затруднён, но не невозможен (хотя крайне желательно подходить к вопросу максимально аккуратно, поскольку любая аудитория сегодня крайне нервно реагирует на автоматический сбор любой статистики).
|
||||
|
||||
Наиболее непростая ситуация с KPI наблюдается, если API в первую очередь способ (техно)пиара и (техно)маркетинга. В этом случае наблюдается накопительный эффект: наращивание аудитории не конвертируется в пользу компании моментально. *Сначала* вы набираете большую лояльную аудиторию разработчиков, *потом* репутация вашей компании улучшается, и ещё более потом эта репутация начинает играть вам на руку при найме. *Сначала* логотип вашей компании появляется на сторонних сайтах и приложениях, *потом* top-of-mind знание бренда увеличится. Нет прямого способа отследить, как то или иное действие (например, релиз новой версии или проведение мероприятия) сказывается на целевых показателях. В этом случае приходится оперировать косвенными показателями — посещаемость ресурсов для разработчиков, количество упоминаний в тематических сообществах, помещаемость блогов и семинаров и т.п.
|
||||
|
||||
Кратко суммируем вышесказанное:
|
||||
* считать прямые показатели, такие как общее число пользователей и партнёров, — гигиенический минимум, без которого сложно двигаться дальше, но это не KPI;
|
||||
* KPI для продукта API должен выставлять исходя из количества целевых действий, которые производятся через платформу;
|
||||
* определение «целевых действий» зависит от модели монетизации и может быть как прямолинейным «количество платящих клиентов» или «количество кликов по рекламе», так и достаточно опосредованным и эвристическим типа «количество посетителей блога команды разработки».
|
||||
* определение «целевых действий» зависит от модели монетизации и может быть как прямолинейным «количество платящих клиентов» или «количество кликов по рекламе», так и достаточно опосредованным и эвристическим типа «количество посетителей блога команды разработки».
|
||||
|
||||
#### SLA
|
||||
|
||||
Невозможно в этом разделе не упомянуть и о «гигиеническом KPI» — уровне предоставляемых услуг и доступности сервиса. Мы не будем здесь давать детального описания, поскольку SLA API ничем не отличается от SLA других видов цифровых сервисов, отметим лишь то, что следить за ним, разумеется, надо, особенно в случае платных API. Впрочем, во многих случаях провайдеры API обычно ограничиваются достаточно свободным SLA, трактуя тарифицируемые услуги как услуги доступ к информации или лицензирование контента.
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
В контексте работы с API мы говорим о двух видах пользователей системы:
|
||||
|
||||
* пользователи-программисты, т.е. непосредственно ваши клиенты, разрабатывающие код поверх вашего API;
|
||||
* конечные пользователи, которые будут работать с приложениями, написанными программистами на вашем API.
|
||||
* пользователи-партнёры, т.е. непосредственно ваши клиенты, разрабатывающие код поверх вашего API;
|
||||
* конечные пользователи, которые будут работать с приложениями, написанными партнерами с использованием вашего API.
|
||||
|
||||
И тех, и других в большинстве случаев необходимо уметь идентифицировать, т.е. иметь ответы на следующие вопросы:
|
||||
|
||||
@ -37,7 +37,11 @@
|
||||
|
||||
Так или иначе, встаёт вопрос независимой валидации: каким образом можно проконтролировать, действительно ли API используется конечным потребителем в соответствии с пользовательским соглашением.
|
||||
|
||||
Мобильные приложения удобно отслеживаются по идентификатору приложения в соответствуюем сторе (Google Play, App Store и другие), поэтому разумно требовать от партнёров идентифицировать приложение при подключении API.
|
||||
Мобильные приложения удобно отслеживаются по идентификатору приложения в соответствуюем сторе (Google Play, App Store и другие), поэтому разумно требовать от партнёров идентифицировать приложение при подключении API. Вебсайты с некоторой точностью можно идентифицировать по заголовкам Referer или Origin.
|
||||
|
||||
Общий вывод из вышеизложенного таков:
|
||||
* очень желательно иметь формальную идентификацию пользователей (API-ключи как самая распространённая практика, либо указание контактных данных, таких как домен вебсайта или идентификатор приложения в сторе, при инициализации API);
|
||||
* доверять этой информации безусловно ни в коем случае нельзя: должны существовать механизмы проверки, которые позволяют найти подозрительные запросы.
|
||||
|
||||
#### Идентификация конечных пользователей
|
||||
|
||||
@ -57,4 +61,3 @@
|
||||
2. Дополнительным способом идентификации служат уникальные идентификаторы пользователей, в первую очередь — cookie. Однако в последние годы этот способ ведения статистики подвергается атаке с нескольких сторон: производители браузеров ограничивают возможности установки cookie третьей стороной, пользователи активно защищаются от слежения, и законодатели начали выдвигать требования в отношении сбора данных. В рамках текущего законодательства проще отказаться от использования cookie, чем соблюсти все необходимые требования.
|
||||
|
||||
Всё это приводит к тому, что публичным API, особенно используемым в бесплатных сайтах и приложениях, очень тяжело вести статистику, а значит и тяжело анализировать поведение пользователей. И речь здесь не только о борьбе с разного рода фродом, но и банальном анализе сценариев использования API.
|
||||
|
||||
38
src/ru/drafts/04-Раздел III. API как продукт/09. Фрод.md
Normal file
38
src/ru/drafts/04-Раздел III. API как продукт/09. Фрод.md
Normal file
@ -0,0 +1,38 @@
|
||||
### Фрод и информационная безопасность
|
||||
|
||||
Как мы неоднократно упоминали, API выступает мультипликатором *любых* возможностей — в том числе и противозаконных: серьёзная уязвимость в API означает, что проблемам подвержены *все* клиенты, и это может приводить к проблемам совсем другого масштаба, нежели уязвимость в отдельном сервисе. Поэтому обеспечение безопасности API должно иметь максимальный приоритет из возможных.
|
||||
|
||||
Любой ИТ-сервис под капотом работает через внутренние API, которые, как правило, и являются главной мишенью злоумышленников. В этом смысле корпус возможных векторов атаки на API и на сервис для конечного пользователя почти полностью совпадает. На общих проблемах информационной безопасности мы останавливаться не будем, поскольку это тема для отдельной книги. Выделим же здесь те, которые специфичны именно для API как продукта.
|
||||
|
||||
##### Автоматическая генерация запросов
|
||||
|
||||
Речь идёт о следующем сценарии: допустим, ваш партнёр использует в своём приложении функцию поиска кофеен в виде эндпойнта для конечных пользователей (который «под капотом» вызывает соответствующую платную функциональность вашего API). Злоумышленик может вызывать этот эндпойнт автоматически (роботом), который эмулирует поведение обычного пользователя, и тем самым свободно пользоваться API. Основной и по факту единственный способ борьбы с таким фродом — не перекладывать на плечи партнёра борьбу с фродом, а встроить её в сам API. В частности, чрезвычайно полезно с самого начала закладывать возможность показывать конечному пользователю captcha, если он ведёт себя подозрительно. Другой способ борьбы — это honeypot-ы, т.е. «приманки», по которым может перейти только робот, но не законопослушный пользователь (типа невидимых результатов поиска).
|
||||
|
||||
Весьма полезным может оказаться подсчёт агрегированной статистики по сетям, о которой мы писали в предыдущей главе. Большое количество запросов с одного ip или одной сети (особенно если они относится к известным публичным прокси или выходным нодам TOR) является хорошим маркером необходимости показать captcha.
|
||||
|
||||
Очевидно, что добавление любого из описанных механизмов — нарушение обратной совместимости, поэтому их необходимо предусматривать с самой первой версии API.
|
||||
|
||||
##### Кража токенов доступа к платным API
|
||||
|
||||
Вопрос частично обсуждался в предыдущей главе: ключи доступа достаточно легко извлечь из кода клиентских приложений; это означает, что, предоставляя любую функциональность в виде SDK, виджетов и любых других клиентских компонентов вы автоматически создаёте возможность для злоумышленника представиться законопослушным партнёром и не платить за использование API (более того — переложить бремя оплаты на партнёра). Серверный ключ тоже может случайно утечь или быть украден. С такими нарушениями необходимо бороться комплексно.
|
||||
|
||||
1. Настроить распознавание роботов, как описано выше, и игрегацию статистики по автономным сетям (см. предыдущую главу). Скорее всего, украденные ключи будут использоваться не в приложении для конечных пользователей, а для какой-то непубличной деятельности, а значит будут хорошо отлавливаться обоими видами фильтров.
|
||||
|
||||
2. Дать возможность партнёрам ограничивать функциональность, которая доступна по ключу:
|
||||
* устанавливать диапазон допустимых IP-адресов для серверных API, идентификаторов приложений и хостов в клиентских API;
|
||||
* разрешать использование конкретного ключа только для конкретных методов API;
|
||||
* вводить иные разумные ограничения (например, для ключа нашего кофейного API можно установить ограничения по странам и городам, в которых работает партнёр).
|
||||
|
||||
3. Вводить дополнительное подписывание запроса:
|
||||
* например, если на странице вебсайте партнера осуществляется поиск лучших предложений лунго, для чего клиент обращается к URL вида `/v1/search?recipe=lungo&api_key={apiKey}`. В этом случае API-ключ может быть заменён на сгенерированную сервером подпись вида `sign = HMAC("recipe=lungo", apiKey)`. Такая подпись может быть украдена, но будет бесполезна для злоумышленника, так как позволяет найти только лунго;
|
||||
* вместо API-ключа можно использовать одноразовые пароли (Time-Based One-Time Password, TOTP); такие токены действительны, как правило, в течение минуты, что чрезвычайно затрудняет злоумышленнику работу с украденными ключами.
|
||||
|
||||
По сути, описанные выше методы — вариации существующих алгоритмов защиты авторских прав (DRM, Digital Rights Management), поскольку конечная цель защиты та же: не допустить несанкционированного использования данных, доступных клиенту. И, как и в случае DRM, недостаток этого подхода — это необходимость законопослушным пользователям тратить время и ресурсы на работу с такой защитой. Любые технологии подобного рода — это всегда некоторые эвристические способы увеличить стоимость атаки настолько, чтобы она стала невыгодной.
|
||||
|
||||
Существует мнение, что любые активные способы защиты скорее вредят API, из-за сочетания двух факторов:
|
||||
* бороться с выявленным нарушением вам, скорее всего, придётся административными методами, т.е. путём написания жалоб в магазины приложений и хостерам «пиратских» сайтов; для этого важно, чтобы доказательства нарушения были просты и очевидны, в то время как продемонстрировать факт взлома сложных DRM-алгоритмов может быть далеко не тривиальной задачей;
|
||||
* вводя сложные алгоритмы, вы тем самым проводите своеобразный эволюционный отбор, направленный на выявление самых умных и хитрых злоумышленников, противодействовать которым будет гораздо сложнее, чем наивным попыткам украсть ключи.
|
||||
|
||||
С нашей точки зрения лучшей политикой борьбы с фродом является пассивный мониторинг нарушений (с последующим принятием административных мер) плюс возможность партнерам по их желанию установить дополнительные технические ограничения.
|
||||
|
||||
**NB**. Описанные выше разнообразные методы борьбы с нарушителями подразумевают, что вы предусмотрели процедуры отзыва ключа — как технические (обеспечение минимальной сложности процедуры смены ключа), так и организационные (уведомление партера о компрометации ключа) — иначе вы попросту ничего не сможете сделать с выявленными фактами фрода.
|
||||
@ -8,13 +8,15 @@
|
||||
|
||||
3. Если через API осуществляется сбор UGC-контента.
|
||||
|
||||
Первые два сценария по сути представляют собой ошибки продуктового или технического развития API, и их желательно не допускать. Третий сценарий не имеет особенной API-специфики, он по факту мало отличается от поддержки пользователей на основном UGC-сервисе. Поддержку же собственно API можно разделить на два больших раздела:
|
||||
Первые два сценария по сути представляют собой ошибки продуктового или технического развития API, и их желательно не допускать. Третий сценарий не имеет особенной API-специфики, он по факту мало отличается от поддержки пользователей на основном UGC-сервисе.
|
||||
|
||||
Поддержку же собственно API можно разделить на два больших раздела:
|
||||
* юридическая и организационная поддержка по вопросам условий использования и SLA сервиса (здесь скорее речь идёт об ответах на вопросы бизнес-партнёров);
|
||||
* поддержка разработчиков по возникающим техническим вопросам.
|
||||
|
||||
Первый раздел, несомненно, критически важен для любого здорового продукта (включая API), но вновь не содержит в себе какой-то особенной специфики. С точки зрения содержания настоящей книги нас гораздо больше интересует второй раздел, поскольку здесь специфика имеется.
|
||||
Первый раздел, несомненно, критически важен для любого здорового продукта (включая API), но вновь не содержит в себе какой-то особенной специфики. С точки зрения содержания настоящей книги нас гораздо больше интересует второй раздел.
|
||||
|
||||
Поскольку API — программный продукт, разработчики фактически будут задавать вопросы о работе того или иного фрагмента кода, который они пишут. Этот факт сам по себе задирает планку требований к качеству специалистов поддержки до очень высокого уровня, поскольку прочитать код и понять причину проблемы может только разработчик же. Но это полбеды: другая сторона проблемы заключается в том, что, как мы упоминали в предыдущей главе, львиная доля этих запросов будет задана неопытными или непрофессиональными разработчиками, что в случае любого сколько-нибудь популярного API приводит к тому, что 9 из 10 запросов *будут вовсе не про работу API*. Начинающие разработчики плохо владеют языком, обладают фрагментарными знаниями об устройстве платформы и не умеют правильно формулировать свои проблемы (и как следствие не могут поискать ответ на свой вопрос в Интернете перед тем; хотя, будем честны, в большинстве случаев даже и не пробуют).
|
||||
Поскольку API — программный продукт, разработчики фактически будут задавать вопросы о работе того или иного фрагмента кода, который они пишут. Этот факт сам по себе задирает планку требований к качеству специалистов поддержки до очень высокого уровня, поскольку прочитать код и понять причину проблемы может только разработчик же. Но это полбеды: другая сторона проблемы заключается в том, что, как мы упоминали в предыдущих главах, львиная доля этих запросов будет задана неопытными или непрофессиональными разработчиками, что в случае любого сколько-нибудь популярного API приводит к тому, что 9 из 10 запросов *будут вовсе не про работу API*. Начинающие разработчики плохо владеют языком, обладают фрагментарными знаниями об устройстве платформы и не умеют правильно формулировать свои проблемы (и как следствие не могут поискать ответ на свой вопрос в Интернете перед тем; хотя, будем честны, в большинстве случаев даже и не пробуют).
|
||||
|
||||
Вариантов работы с такими обращениями может быть несколько.
|
||||
|
||||
@ -24,7 +26,7 @@
|
||||
|
||||
3. Частично или полностью проблему с поддержкой новичков может снять развитое комьюнити (см. соответствующую главу). Как правило, члены комьюнити в состоянии ответить на вопросы новичков, особенно если им активно помогают модераторы.
|
||||
|
||||
Важный момент заключается в том, что, какой вариант оказания техподдержки вы ни выберете, финально на вопросы пользователей придётся отвечать разработчикам API просто в силу того факта, что полноценно разобраться в коде партнёра может только программист. Из этого факта следуют два важных вывода:
|
||||
Важный момент заключается в том, что, какой вариант оказания техподдержки вы ни выберете, финально на вопросы пользователей придётся отвечать разработчикам API просто в силу того факта, что полноценно разобраться в коде партнёра может только программист. Из этого следует два важных вывода:
|
||||
|
||||
1. Время на оказание технической поддержки необходимо закладывать при планировании. Чтение совершенно незнакомого кода и удалённая его отладка — крайне сложная и отнимающая большое количество времени задача. Чем больше функциональности вы публикуете и чем больше платформ поддерживаете, тем выше будет нагрузка на команду разработки в части разбора обращений.
|
||||
|
||||
@ -33,3 +35,7 @@
|
||||
* остаточная нагрузка на команду должна быть распределена максимально равномерно и честно, вплоть до введения календаря дежурств.
|
||||
|
||||
Разумеется, полезным упражнением будет анализ вопросов и ответов с целью дополнения FAQ-ов, внесения изменений в документацию и скрипты работы первой линии поддержки.
|
||||
|
||||
#### Внешние платформы
|
||||
|
||||
Рано или поздно вы обнаружите, что пользователи задают вопросы о работе с вашим API не только через официальные каналы, но и на многочисленных публичных интернет-площадках, начиная от специально предназначенных для этого сервисов типа StackOverflow и заканчивая социальными сетями и личными блогами. Тратить ли на поиск подобных обращений время — решать вам; мы бы рекомендовали оказывать техническую поддержку на тех площадках, которые предоставляют для этого удобные инструменты (типа возможности подписаться на новые вопросы по конкретным тэгам).
|
||||
@ -0,0 +1,25 @@
|
||||
### Управление ожиданиями
|
||||
|
||||
Наконец, последний аспект, который хотелось бы осветить в рамках данного раздела — это управление ожиданиями партнёров в отношении развития вашего API.
|
||||
|
||||
#### Версионирование и жизненный цикл приложений
|
||||
|
||||
Конечно, в идеальном случае однажды выпущенный API должен жить вечно; но, как разумные люди, мы понимаем, что в реальной жизни это невозможно. Даже если мы продолжаем поддерживать старые версии, они все равно морально устаревают: партнёры должны потратить ресурсы на переписывание кода под новые версии API, если хотят получить доступ к новой функциональности.
|
||||
|
||||
Мы формулируем золотое правило выпуска новых версий API так: период времени, после которого партнеру потребуется переписать свой код, должен совпадать с жизненным циклом приложений в вашей предметной области. Любая программа рано или поздно устареет и будет переписана; если в рамках этого перепиывания будет осуществлён и переход на свежую версию API, партнёр, скорее всего, отнесётся к этому с пониманием.Разумеется, в разных областях этот интервал различен, и зависит от скорости эволюции самой нижележащей платформы.
|
||||
|
||||
Помимо переключения мажорных версий API, рано или поздно встанет вопрос и о доступе к минорным версиям. Как мы упоминали в главе «О ватерлинии айсберга», даже исправление ошибок в коде может привести к неработоспособности какой-то интеграции. Соответственно, может потребоваться и сохранение возможности зафиксировать минорную версию API до момента обновления затронутого кода партнёром.
|
||||
|
||||
В этом аспекте интеграция с крупными компаниями, имеющими собственный отдел разработки, существенно отличается от взаимодействия с одиночными разработчиками-любителями: первые, с одной стороны, с гораздо большей вероятностью найдут в вашем API недокументированные возможности и неисправленные ошибки; с другой стороны, в силу большей бюрократичности внутренних процессов, исправление проблем может затянуться на месяцы, а то и годы. Общая рекомендация здесь — поддерживать возможность подключения старых минорных версий API достаточно долго для того, чтобы самый забюрократизированный партнёр успел переключиться на новую версию.
|
||||
|
||||
#### Поддержка платформ
|
||||
|
||||
Ещё один аспект, критически важный во взаимодействии с крупными интеграторами — это поддержка зоопарка платформ (браузеров, языков программирования, протоколов, операционных систем) и их версий. Как правило, большие компании имеют свои собственные стандарты, какие платформы они поддерживают, и эти стандарты могут входить в заметное противоречие со здравым смыслом. (Например, от TLS 1.2 в настоящий момент уже желательно отказываться, однако многие интеграторы продолжают работать именно через этот протокол, и это ещё в лучшем случае.)
|
||||
|
||||
Формально говоря, отказ от поддержки какой-либо версии платформы — это слом обратной совместимости и может привести к неработоспособности какой-то интеграции у части пользователей. Исключительно желательно иметь чётко сформулированные политики, какие платформы по какому принципу поддерживаются. В случае массовых публичных API ситуация, обычно, достаточно простая (провайдер API обещает поддерживать платформы с долей более N%, или, ещё проще, последние M версий платформы); в случае коммерческих API это всегда некоторый торг — сколько неподдержка той или иной версии протоколов будет стоить компании. Крайне желательно результат этого торга фиксировать в договорах — что конкретно вы обещаете поддерживать и течение какого времени.
|
||||
|
||||
#### Движение вперёд
|
||||
|
||||
Наконец, помимо частных проблем поддержки, ваших пользователей почти наверняка волнуют и более общие вопросы: насколько вам можно доверять; насколько можно рассчитывать, что ваш API продолжит расти, развиваться, будет вбирать в себя современные тренды, и не окажется ли в один прекрасный день интеграция с вашем API на свалке истории. Будем честны: учитывая неопределённость продуктового видения API этот вопрос и нас самих весьма интересует. Даже древнеримский акведук, сохраняющий обратную совместимость вот уже две тысячи лет, уже давно является весьма архаичным и ненадёжным способом решать проблемы пользователя.
|
||||
|
||||
Работать с этими ожиданиями клиентов можно через публичные роадмапы. Не секрет, что многие компании избегают открыто сообщать о своих планах (и не без причины). Тем не менее, в случае API мы всячески рекомендуем роадмапы публиковать, пусть и условные и без конкретных дат, *особенно* если речь идёт о закрытии или прекращении поддержки какой-то функциональности. Наличие таких обещаний (при условии, что разработчик API их выполняет, конечно) — очень важное кокурентное преимущество для всех видов ваших пользователей.
|
||||
@ -1,48 +0,0 @@
|
||||
* Зачем предоставлять API
|
||||
* возможности интеграции с основным сервисом
|
||||
* непрофильные сервисы
|
||||
* концепция API-first
|
||||
* Выгоды наличия API и виды монетизации
|
||||
* API к монетизируемым сервисам (+ Affiliate API)
|
||||
* on-premise
|
||||
* freemium-модели
|
||||
* лимиты
|
||||
* ограничения на типы использования
|
||||
* техническая поддержка
|
||||
* премиум-функциональность
|
||||
* маркетплейсы
|
||||
* рекламные модели
|
||||
* сбор данных / UGC
|
||||
* контакт с брендом
|
||||
* терраформирование
|
||||
* KPI
|
||||
* Прямая и обратная API-пирамида Маслоу
|
||||
* Виды API
|
||||
* API
|
||||
* SDK
|
||||
* виджеты
|
||||
* embedded (включая картинки)
|
||||
* идентификация пользователей и фрод
|
||||
* B2B
|
||||
* Бизнес-аудитория, её интересы и места обитания
|
||||
* SLA
|
||||
* безопасность
|
||||
* идентификация пользователей, ведение статистики, защита публичных ключей
|
||||
* контакты и оповещения
|
||||
* Разработчики, их интересы и места обитания
|
||||
* новички vs продвинутые
|
||||
* OpenSource
|
||||
* Документация
|
||||
* референс
|
||||
* tutorial
|
||||
* how-to
|
||||
* примеры
|
||||
* песочница
|
||||
* Тестирование
|
||||
* Промис поддержки платформ
|
||||
* Поддержка пользователей
|
||||
* форумы
|
||||
* поддержка разработчиков
|
||||
* работа с комьюнити
|
||||
* обратная связь (глубина использования фич)
|
||||
* Продуктовое управление разработкой API
|
||||
@ -1,5 +0,0 @@
|
||||
### Фрод
|
||||
|
||||
Фрод (т.е. использование API в нарушение пользовательского соглашения, как правло, для получения какой-то выгоды) можно условно поделить на две категории:
|
||||
* использование различных ухищрений для обхода ограничений на использования API;
|
||||
* использвоание уязвимостей API для несанкционированного доступа к конечным пользователям и/или их данным или ИТ-инфраструктуре самой компании-разработчика API.
|
||||
Loading…
x
Reference in New Issue
Block a user