План битвы API - Сражение за будущее
Публикую перевод статьи API Battle Plans: Fighting for Next, давным-давно сделанный мною в рамках акции 50 лучших SEO-постов 2009 года и благополуно забытый в пылу учебы и работы :) Только чейчас наткнулся на него в Гуглодоках, когда искал кое-какие материалы по одной интересующей меня теме. Тем не менее, лучше уж поздно, чем никогда, посему публикую.
План битвы API - Сражение за будущее
В наши дни API достигли такого уровня зрелости, что все три ключевые компоненты Веба - контент, службы и данные можно легко получить с их помощью. Результатом этого процесса стало ничто иное как рождение новго Веба. Более умного Веба, предоставляющего более релевантную информацию, более удобного и дающего более широкие возможности получения прибыли. После того, как стали очевидны преимущества этого подхода, у современных компаний не осталось иного выбора, кроме как поддерживать суперструктуру API, столпами которой являются контент, сервисы, разработка и аналитика.
Но с чего дальновидному бизнесу начинать?
Несмотря на то, что API уже довольно давно применяются для доступа к информации, мы все еще находимся в состоянии зарождения API для контента и сервисов. Удивительно, но мы находимся в еще более зачаточном состоянии в отношении применения API для оптимизации цифровых носителей и представления информации. Вы можете себе представить полностью динамическую Сеть? Я знаю, это может показаться непростым, имея за плечами опыт мешапов, которые мы оставляем позади вместе с остальной эпохой Веб 2.0.
Окружающий нас Веб требует применения стратегий, распространяющих вездесущность динамического Веба, и API являются ключом к достижению этого. Так же будет играть важную роль и Семантический Веб (или более новый термин «связанные данные»). Ниже я постараюсь как можно яснее изложить свои мысли о том, как стартапы, прежние цифровой и традиционный бизнес могут применять стратегию API для своего дела. Так же я с удовольствием выслушаю ваше мнение по этому вопросу в комментариях. Единственное, что я абсолютно точно знаю — это какими последствиями грозит отсутствие подробного плана битвы для тех, кому придется иметь с этим дело.
Bit.ly: Модель армии
Существует много подходов к использованию общедоступных источников контента и данных, но все равно до тех пор пока вы не создадите нечто, что объединяет ключевые компоненты API (контент, сервисы, разработка и аналитика), вы всегда будете уязвимы или будете проигрывать конкурентам. Хорошим примером этому может служить сокращение ссылок.
Существует не так уж и много сервисов сокращения ссылок и из них лишь bit.ly объединяет контент (страница, на которую он ссылается), сервис (сокращение ссылок), разработку (платформа Calais) и аналитику (статистика кликов). Вместе все компоненты дают нечто большее, чем по отдельности, но даже сами по себе они могут быть полезны в различных случаях, в зависимости от целей пользователя (и направления развития бизнеса bit.ly). Этот многоуровневый подход и стал причиной прорыва, совершенного bit.ly, и того, почему это хороший пример для изучения, как создавать решения на базе API.
Так что давайте вместе углубимся в каждый из компонентов API взаимодействия с Вебом и посмотрим, что мы можем из этого почерпнуть.
КСРА (CUDA): Стек API.
Сегодня все любят говорить о разнообразных стеках, поэтому я представлю план битвы за API в вашей организации именно в этом стиле.
Я называю это КСРА (CUDA) потому что… просто потому что я маркетолог и это звучит круто.
Уровень 1. Контентные API: тексты, картинки, звук и видео.
Поскольку Веб — это в первую очередь носитель информации, контентные API предлагают наибольшие возможности, но вместе с тем и создают наибольшую сложность. Единственная фактор, ограничивающий успех контент-провайдеров это, видимо, они сами. Создание же API — это всего лишь один из уровней стека.
В New York Times верят, что их API в 2,5 раза увеличит охват аудитории. Но как? Зависеть от неизвестных третьих лиц в превращении ваших API в вашу прибыль — это сродни менеджеру по продажам, просто сидящему у телефона и ждущему пока он зазвонит. Контентные API - это лишь сырой материал, и то, получите ли вы в результате уголь или алмазы, зависит от того, как вы его обработаете.
Единственная проблема издателей — это то, что они никогда не были сильны в цифровом маркетинге или технологических инновациях. Вдобавок, технологические инновации всегда скептически воспринимаются издателями. Уже тот факт, что Kindle приносит Amazon’у прибыть от подписок на Wall Street Journal большую, чем получает сам WSJ (не принимая во внимание прямые потери прибыли и отношения покупателей для журнала), должен быть достаточной мотивацией для того, чтобы заняться созданием собственного решения. Но когда это произойдет в действительности пока предсказать невозможно.
Уровень 2. Сервисные API: сообщения, платежи, цены.
Очевидно, что обмен сообщениями, платежи и другие основанные на API инструменты уверенно лидирует в отношении наиболее творческого применения API. Мы уже сталкивались с этим, когда API Твиттера породило массу сторонних приложений, заполнивших его экосистему, и некоторые их которых даже были поглощены или вступили в партнерские отношения с самим Твиттером. И я полагаю, эту область в будущем году ждет взрывной рост. Интеграция сервисов — это однократное вложение с долговременной отдачей для ключевых платформ. Для предпринимателей и венчурных капиталов этот шаг так же представляет возможность получения быстрой прибыли.
Уже в ближайшее время пред нами предстанет множество платежных API во главе со многоожидаемой платежной системой Facebook. В моей собственной компании RAMP Digital мы встроили мобильный платежный API в отображение рекламы, чтобы облегчить заказ подписки прямо из рекламного блока. И подобные решения — это лишь начало новой волны служб, доступных через API.
Уровень 3. Разработка: службы API.
Как ни крути, разработка — это всегда ключевой уровень. Главные инновации на пути к настоящему Вебу услуг будут построены на их основе. Яркий пример — http://camelbuy.com. C помощью BestBuy API он предоставляет массу ценной и полезной информации. Это хорошее начало, но бизнес не может успокоиться, уповая на то, что успех их API будет обеспечен сторонними разработчиками, получающими партнерские отчисления или победителями конкурсов.
Моя предыдущая компания (Offermatica) создала великолепный инструмент для веб-сервисов. Вместо обращений к API мы сделали обращения к JavaScript. Тем не менее, будучи оставлены наедине со своими компьютерами, пользователи сами даже близко не сумели использовать весь потенциал технологии. И это типичная история для новой технологии. Если людям что-то слишком сложно, то они просто не будут им пользоваться. Это вездесущий человеческий фактор.
От творческих и медийных агентств будет мало пользы, и мое предсказание не сбудется до тех пор, пока не появятся предоставляющие услуги компании, которые хорошо поняли технологию и развили соответствующие методологии (с получением результата). Без сервисов, боюсь, не будет ни примеров для изучения, ни основоположников, ни конкуренции и абсолютно никакого улучшения производительности Веба. Но зачем строить этот бизнес, если нет клиентов? Или, если вы такой умный, не взять и сделать самому?
Если что и сдерживает будущее Веба, то это не оптимизация доставки контента, а оптимизация его представления.
Уровень 4. Аналитическое API: Профили данных, параметры.
Данные, предоставляемые через API, уже оказали значительное влияние на Веб. Google в день обрабатывает 4 миллиарда обращений к своим API (представьте на секунду, какое преимущество они имеют в отношении реализации сбора аналитики).
Сейчас уже видны итоги первого десятилетия коммерческого Веба. Нынешняя вторая волна — это приход понимания, переломным фактором в котором являются данные реального времени. Реальное время изменит все, начиная от доставки контента и заканчивая динамическими системами регулировки цен на рекламу и трафик.
Кроме того, мы переходим от Веба-в-браузере к Вебу, где все что угодно может отправить запрос, а не только браузер. И все это требует новых методов сбора и анализа данных, а так же новых способов оптимизации. В то же время, хорошей стороной является то, что мы можем применять API для упрощения этой задачи.
Итог
Лидерами первого десятилетия коммерческого Веба стали такие сайты, как Amazon и Google, ориентированные на производительность, удобство использования, тестирование и оптимизацию доставки актуальных данных и получении выгоды. Лидерами следующего десятилетия станут те, кто применит те же принципы к тому, как они собирают и развивают контент, сервисы и данные, предоставляемые через API. В настоящее время мы заняты оптимизацией того, как мы структурируем то, что нам предлагает Веб. И в отличие от прошлого, сейчас он предлагает нам все.
