Будущее API в 2014 году

Original author: Steven Willmott
  • Translation
2013 был ознаменован впечатляющими достижениями в развитии технологии API, а также в ее популяризации и инвестициях в эту сферу. Количество API, отмеченных в ProgrammableWeb, впервые перевалило за 10 000, произошли серьезные денежные вливания и поглощения, связанные с этой технологией, было организовано множество новых конференций, включая нашу собственную конференцию API Strategy and Practice, проведенную совместно с API Evangelist. 2013 отметился и новыми инициативами, такими как API Commons, в рамках которой участники пытаются решить долгосрочные задачи различных отраслей экономики.

Количество действующих пользовательских API, которые мы поддерживаем в рамках нашей платформы по управлению API, возросло за прошедший год в 2 раза – и точно так же вырос API-траффик. Поэтому после такого впечатляющего 2013-го мы задались вопросом: что готовит нам новый 2014-й? И вот наши прогнозы!

1. (Как и следовало ожидать) рост API: очевидный первый прогноз, согласно которому в 2014 году появится множество новых API – все показатели свидетельствуют о том, что их количество будет только возрастать. Количество публичных API, отмеченных в широко известных перечнях, только что достигло 10 000, а существует еще огромное количество частных или полу-публичных API, количеством значительно превосходящих публичные API. К этим частным API относятся интерфейсы, принадлежащие к бурно развивающимся категориям, включающим мобильный бэкенд; API для SAAS-интеграции; API, заменяющие собой интеграцию «тяжеловесных» B2B-решений и даже API для аппаратного обеспечения домашней электроники типа Philips Hue lightbulb.

В 2014 мы ожидаем, что количество публичных и частных API, создающихся в рамках этих направлений вырастет в пределах от 100 000 до 200 000 – к нижней границе этого количества мы уже приблизились, если верить подсчетам, согласно которым соотношение частных API к публичным составляет 9:1. Мы ожидаем, что рост API будет происходить в двух направлениях: во-первых, будут выходить новые API (в качестве индикаторов такого роста мы в 3scales отмечаем сотни новых регистраций и десятки запускающихся API каждый месяц), во-вторых, постепенно будет увеличиваться доступность множества частных API, поскольку компании стремятся выйти на существенно более широкую аудиторию.

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

3. Ключевым вопросом в 2014 году станет вопрос авторского права на API: с возобновлением дела о копирайте между Oracle и Google Java к нам вновь вернулось предчувствие грядущего ужесточения требований к спецификациям API, а дело, если текущее решение объявят недействительным, может иметь далеко идущие последствия – вплоть до того, что определенные паттерны интерфейсов будут защищаться авторским правом от повторного использования. Хотя в некоторых случаях такая защита может быть оправдана, применение авторского права к API может оказать негативный эффект на развитие инноваций, поскольку «успешно» оградит широко используемые и важные паттерны от применения сторонними компаниями. Такие инициативы, как API Commons, могут помочь построить основу для повторно используемых паттернов – но подобные проекты находятся на начальных этапах развития, поэтому споры вокруг авторского права будут важной частью 2014 года.

4. В центре внимания окажутся технологии описания сервисов: одна из ключевых сложностей для REST API заключается в том, что API-провайдеры практически никогда не публикуют выделяемые и перемещаемые метаданные о своих API, которые можно найти и обработать. Хотя в настоящее время доступны некоторые развивающиеся форматы типа WADL и Swagger, и новые форматы вроде Blueprint и RAML, они решают проблему в лучшем случае частично и не распространены. Это отсутствие автоматизированных описаний затрудняет весь процесс работы с API, начиная с генерации stub-библиотек и заканчивая нахождением API – например, API поискового движка вряд ли появится до того, как публикация таких электронных описаний станет нормой.

В результате мы ожидаем возникновение дебатов, связанных с индустрией и лучшими практиками, о том, какие форматы заимствовать, и появление соглашений относительно того, как их публиковать/находить. Без этого, вероятно, невозможно будет организовывать публичные площадки для API, такие как ProgrammableWeb.

5. Появятся новые API-агрегаторы: с ростом количества API, появляются проекты «middle-уровня», такие, как Segment.IO, Zypr и другие, позволяющие объединять несколько API одного конкретного сегмента в единый адресуемый API. Агрегатор такого типа создает единую точку интеграции для нескольких бэкенд-API. В некоторых случаях решения, предлагаемые агрегаторами, могут показаться ненадежными из-за особенностей API, которые они объединяют, однако в остальных случаях их ждут с распростертыми объятиями, поскольку решения агрегаторов сокращают сложность проекта для разработчиков и уменьшают затраты на прямую поддержку. С увеличением количества API растет и число областей, в которых будут появляться агрегаторы. Темпы использования API опережают скорость их создания, что в сочетании ведет к следующему прогнозу…

6. Активно развиваться будут инструменты разработки API: сегодня множество инструментов для разработки API от различных вендоров, таких как, например, мы, Mashery, Apigee и другие, сфокусированы на обеспечении владельцам API возможности предоставлять свои API третьим лицам. Это важная технология, которую сейчас используют повсеместно. Однако до недавнего времени существовало сравнительно немного инструментов для «потребителей» API – в частности для того, чтобы разработчики осуществляли дебаггинг, мониторинг и трекинг использования API в рамках своих приложений. В 2013 году появилось несколько компаний, призванных решить эту задачу – среди них такие фирмы, как Runscope и API Science. Еще больше подобных организаций появятся в этом году – включая и новое предложение от 3scale. Инновации для разработчиков, использующих API, стали крайне важны, поскольку в настоящее время даже разработчики, использующие хорошо задокументированные API, испытывают трудности и разочарования на пути к своей цели.

7. Single Page Application станет новым двигателем развития API: архитектура Single Page Application Architectures (или SPA) для веб-приложений, написанных на HTML, реализация которой стала возможной с появлением HTML5, в настоящее время претерпевает значительный рост. SPA-концепция подразумевает использование HTML, CSS3 и Javascript для создания приложения, которое работает, выгружая единственную HTML-страницу в веб-браузер и затем выполняя все функции, заложенные в приложение, за счет запросов API к бэкенд-серверу – в таком приложении вы не переходите на новые веб-страницы. Мы уже писали о влиянии этой технологии на API [1, 2] и наблюдаем развитие данного тренда. В частности, начинают набирать популярность такие Javascript-фремворки, как Angular.js, инструменты разработки эволюционируют, и новые фреймворки, такие как Famo.us, делают непростой процесс разработки на JS исключительно привлекательным для Веба.

Как результат, мы ожидаем, что архитектура SPA начнет становиться нормой для бизнес-приложений/функциональных приложений в 2014 году и постепенно станет использоваться также в электронной коммерции и ритейле.

8. API для гипермедиа будут наращивать популярность: API, работающие с гипермедиа, более гибкие по сравнению с традиционными, поскольку в ответах, возвращаемых на запросы таких API, содержатся определенные «разрешенные» действия (более подробно этот процесс описан здесь), предоставляющие API возможность динамически менять содержание запросов и тем самым адаптироваться к текущей ситуации. Тем не менее, сейчас тем, кто предпочитает API, работающих с гипермедиа, API-интерфейсам, использующим статичные URL, все еще приходится идти на компромиссы, хотя в настоящее время крупномасштабное развертывание этой технологии наблюдается в API-интерфейсах от Public Media Platform и недавно выпущенном Appstream API от Amazon.

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

9. API, работающие с данными гражданских институтов, станут прорывом года: в попытке предсказать, какие категории API будут расти быстрее других, мы все время возвращались к API, использующим информацию гражданских институтов. Руководство крупных городов, таких как Нью-Йорк, Чикаго, Сан-Франциско, Амстердам, Хельсинки, уже сделало доступным большие объемы данных, так что сейчас настало время API, предоставляющих горожанам данные о городской инфраструктуре. А горожане, в свою очередь, смогут на их основе создавать приложения и мэшапы, визуализировать полученную информацию. Этот тренд становится все более и более популярным – особенно в связи с тем, что госучреждениям непозволительно дорого обходится создание всех веб- и мобильных приложений, которые оказываются нужны горожанам: таким образом, доступ к подобной информации открывает новое направление для инноваций и возможностей для жителей городов помочь самим себе. Другая причина роста популярности этого направления заключается в том, что инициативы, подобные open311, CitySDK и CityProtocol, активно стараются стандартизировать некоторые из таких интерфейсов для большого количества городов, что должно ускорить адаптацию технологии и одновременно расширить рынки потребления приложений, использующих подобные данные.

10. Продолжат расти и развиваться такие нативные веб-технологии, как openAuth, JSON и другие: в 2012-13 годы XML начал терять свою популярность в плане поддержки публичных API – восходящим трендом в этом направлении стал JSON. Были даже случаи, когда компании, ранее работавшие с XML, прекратили поддержку этой технологии. Этот тренд был характерен и для 2013 года, отмеченного появлением множества новых API, ориентированных в первую очередь на JSON и в гораздо меньшей степени на XML. Этот тренд, наравне с популяризацией других веб-ориентированных стандартов, будет, вероятно, сохранять силу и в 2014 году, учитывая, что мобильный и HTML5 + Javascript положительно влияет на рост количества API. Даже там, где API служат преимущественно для B2B-интеграции (ранее бывшей прерогативой SOAP/XML), в качестве дополнительных опций активно рассматриваются мобильные сценарии, которые соответствующим образом влияют на выбор конечной технологии.

Итак, 2014 открывает перед нами захватывающие перспективы и, без сомнения, готовит немало сюрпризов! Мы с нетерпением ждем возможности подтвердить или опровергнуть свои предположения, а также узнать о чем-то новом и неожиданном.

[Fabernovel, в свою очередь, работает над практическими семинарами по данному направлению, и если в вашей компании есть понимание того, что двигаться в сторону работы с API необходимо и перспективно, первым шагом может быть участие в таком семинаре и работе с нашими экспертами… Это, во многом, уникальное предложение, так что, если вы заинтересовались – пишите нам.]
FaberNovel
Company
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 5

    +13
    Ну вот, теперь и слово API превратилось в buzzword. Можно добавлять в bullshit bingo.
      +3
      TL;DR

      Туча народу почему-то возомнила, что опубликовать документацию к ручке — это сделать API.
      Другая туча народу теперь успешно кормится на этом празднике дилетантства.
      Ну и да, булшит-бинго можно рисовать по этому посту.
        +3
        Весь пост преследовало ощущение того, что API — эта совсем не та аббревиатура, к которой я привык.
          +1
          Подставь любимое слово: i023.radikal.ru/1405/65/b54be23fbc65.png
            0
            Добрую половину поста не мог понять про какие именно API тут говориться. Автор либо не понимает что понятие API гараздо шире чем Web (http based) API, либо стоило сделать уточнение еще в начале статьи. И кстати REST, который промелькнул в статье, это тоже не более чем один из принципов, которого можно придерживаться проектируя подобные ручки. В общем комментарии выше точно описали мои ощущения от использования терминов в посте.

            Но как бы там ни было, спасибо, местами было интересно. Пропиариться у вас тоже получилось)))

            Only users with full accounts can post comments. Log in, please.