Статьи

Flickr, Zooomr и API Parity

Следующее переиздано из Tech Times # 141 .

Проблема, о которой я говорил в своей редакционной статье о подключении к Web 2.0, на этой неделе всплыла на поверхность с новостями о том, что Flickr отклонил запрос конкурента Zooomr на доступ к API Flickr, чтобы Zooomr мог импортировать фотографии и метаданные Flickr пользователей (например, теги). для них.

Теперь, прежде чем вы попадете на путь войны, я должен отметить, что Flickr в прошлом одобрил запросы на доступ к API от других конкурентов, таких как Riya и Tabblo . Однако кое-что о прямой конкуренции, которую Zooomr представлял для Flickr, перевесило чашу весов, и Flickr сделал колл. По электронной почте Zooomr:

… Мы решили не поддерживать использование API для сайтов, которые являются прямой альтернативой Flickr.

Основатель Стюарт Баттерфилд даже поделился своими соображениями на форумах FlickrCentral:

Что касается предоставления коммерческой лицензии API прямому конкуренту: мы не можем. […] В случае действительно прямого конкурента (а пока у нас очень мало), мы, вероятно, не будем. И я не считаю это злонамеренным с нашей стороны: почему мы должны сжигать полосу пропускания и циклы ЦП, отправляя данные прямо на их серверы?

Это, понятно, вызвало серьезную дискуссию. Когда ответственные компании, такие как Yahoo! утверждаете, что их сервисы открыты, что позволяет пользователям получать любые данные, которые они в них помещают, имеют ли они право делать это менее удобным, когда то, что вы хотите сделать с вашими данными, это перенести их в конкурирующий сервис?

После внутреннего обсуждения вопроса Баттерфилд пересмотрел свою позицию :

Я действительно изменил свое мнение и был убежден позицией Эрика, что мы определенно должны одобрять запросы от прямых конкурентов, если они делают то же самое. Это означает (а), что они должны иметь полный и полный API и (б) быть готовыми предоставить нам доступ.

Причиной здесь является то, что «справедливая справедливость» и, более тонко, как лицензия GPL, обеспечивают свободу пользователей в цепочке. Я думаю, что мы примем этот подход (все еще обсуждаем это внутренне).

Это предложение о том, что открытость API между конкурирующими сервисами должна быть улицей с двусторонним движением, было одобрено Марком Хедлундом из O’Reilly и получило название «Паритет API».

В то время как симметрия и встроенная справедливость соглашения выглядят привлекательно с первого взгляда, и это должно решить проблему на благо пользователей в случае с Flickr / Zooomr, я не уверен, что это окончательное решение этой проблемы в Общая.

Я не собираюсь утверждать, что все веб-службы должны быть принудительно вынуждены открывать контент, созданный их пользователями, для простого экспорта. Я, конечно, считаю, что это правильно, и в конечном итоге будет способствовать повышению доверия пользователей к сервису, но, как отмечает Николас Карр , привязка к поставщикам — это проверенная бизнес-стратегия, которая вряд ли скоро исчезнет. Но также всегда будет сегмент пользователей, который настаивает на том, чтобы их данные были открыто доступны для них, и такие службы, как Flickr, будут обслуживать таких пользователей.

О чем я буду спорить, так это о том, что любая такая открытая служба намеренно устанавливает контрольно-пропускные пункты для определенных видов использования данных пользователя. Возвращаясь к делу Flickr / Zooomr, возражение Flickr о предоставлении одностороннего доступа API конкуренту на том основании, что оно «сжигает пропускную способность и циклы ЦП», просто не выдерживает критики. Серверы Flickr будут работать так же быстро, загружает ли пользователь данные и затем загружает их конкуренту вручную, или выполняет прямую передачу конкуренту через API Flickr. Единственное отличие, которое Flickr делает, отказывая в доступе API своих конкурентов, заключается в том, чтобы произвольно снизить удобство его обслуживания, когда пользователи хотят брать свои данные в другом месте.

Таким образом, хотя к так называемому API Parity, безусловно, следует стремиться, это не должно быть условием для открытого сервиса, такого как Flickr, для предоставления доступа к API. Flickr должен заботиться не о своих конкурентах, а о своих пользователях. Сервис просто не открыт, если эта открытость не предоставляется равномерно и без предвзятости.