照片網站的API戰爭：ObjectiveFlickr觀點
前陣子FlickrBooth（TUAW有提過）作者Tristan O’Tierney寄信來和我討論在ObjectiveFlickr中加入Zooomr（註1）與23HQ API支援的可能性，於是研究了一下。
這兩家照片網站都號稱建立了一套和Flickr一模一樣的API layer，在去年春天時還頗引起一陣轟動，特別是Zooomr因為還去跟Flickr申請commercial API key來搬資料，弄得很是熱鬧（以商業觀點，這是很成功的PR戰術）。兩位朋友的試用報告可以看這裡和這裡。
我對照片網站的興趣缺缺，又是Flickr滿意的付費用戶，因此並沒有很想去深入瞭解Zooomr和23HQ有什麼特別的地方（註2）。但是兩家不約而同地跟進使用Flickr API layer是挺有趣的發展。那麼，API developer的眼中看到的Zooomr和23HQ會是怎樣呢？
雖然說Zooomr號稱照著Flickr API做了一套，事實上還沒有完整移植。目前能用的只有upload和簡單的照片查找而已。這個技術選擇，目的不證自明：要讓原本Flickr的上傳工具能無痛移植到Zooomr上。但是簡單兩件事就讓我對目前狀況抱持保留態度：首先，Zooomr必須要使用e-mail來申請API key，而Flickr的non-commercial API key是可以線上申請的。光是這一點就讓想要提供Zooomr支援的人卻步了。雖然ObjectiveFlickr大可不管這事（反正要申請API key的人是那些要寫uploader的），但我也想要有API key來做unit testing或測試我的demo app。如此一來我就只好寫信和等待（他們blog留言上有人說寫信去了很久還沒回音，也不見該公司的人出來澄清）。而在此之前我只好不release Zooomr support了。
除此之外呢，Zooomr的static photo URL規則竟然也和Flickr不同，而Zooomr在blog上竟完全不提這件事，彷彿他們最希望convert的對象，就只有uploader的作者們。而Zooomr在張貼完該篇blog之後，就再也有後續消息啦。Google “Zooomr API” 竟然什麼都沒有，還是找 “Zooomr blog api” 才在第三名找著。光是這樣一陣折騰，我就想轉台了……
至於23HQ呢？其實是因為意外讀到有人藉更換FlickrBooth裡的ObjectiveFlickr來使用23HQ上傳，才知道23HQ原來也照Flickr API複製了一整份。比較起來23HQ就兇狠多啦，不但Flickr API已經移植得差不多了，連手冊也都大方地連到Flickr那邊，不用再多寫什麼。URL endpoint完全無痛轉換，包括static photo URL也都照Flickr格式（23HQ甚至還寫了這個網頁教你怎麼”switch”）。但是比較奇怪的是23HQ竟然提供了Flickr早就不用的舊式authentication（讓使用者把帳號和密碼放在HTTP GET參數裡！）。還有一個不知算是優點還是缺點的東西：23HQ不需要申請API key。照他們的說法，你要不就是自己隨便選一個名字，要不然直接用你在Flickr拿到的API key也是可以的啦…… 這點就讓我不太放心了，總覺得這像是某種收集API key的陰謀（雖然shared secret是收集不到的），除此之外我也在想：不用API key，是否代表API usage monitoring也就隨便做了，難道23 HQ不怕有人寫惡意程式搞死他們的API server嗎……？
23HQ倒是有API forum，這點就比Zooomr強太多了。顯然要在API war中佔塊地，恐怕還是得像Joel曾說的，developers, developers, developers! 但是23HQ只支援REST似乎是致命傷，因為有太多XMLRPC和SOAP的程式庫，這對「傳統」一點的desktop app發展者來說仍然挺重要的。
結論是什麼呢？我想 23HQ 在「照著 Flickr 刻一套」這個criteria上，顯然比 Zooomr 要高明多了。不過 Flickr 的 API 也日新月益，仍然每幾個月又多吐幾條新的 API method 出來，讓大家很是目不暇給（就這點上，Flickr 顯然學到了微軟的招式）。而 Flickr 前陣子也更新了自家 static photo URL 的格式，對上傳和其他工具的開發者來說，大概又有得忙了，如此一來，對23HQ、Zooomr或其他家網站的支援，是否就因此會被擱到較後頭呢……
雖然鄉民們一定會說lock-in是壞事，但Flickr的API已經完整到寫個「把自己所有照片通通搬回來」不是問題的程度，所以「Flickr只進不出」的說法，恐怕是FUD。至於技術上呢，Flickr自己就是自家API的最大消費者（但是要用他們家API做一套跟Flickr一樣的網站則是被禁止的），而Zooomr看來是先有了照片網站，才開始做相容性layer。
ObjectiveFlickr針對23HQ做了一些測試，發現傳回來的response block有一些問題，上傳等候回應的速度也和Flickr完全不能比（不是連線速度，而是傳完照片之後，等待XML response block的時間）。
如是觀之，後發者要靠 API 與大玩家搏一局，或者要爭取 developers 跳船換旗，看來還有很多關鍵細節得照顧。
（ObjectiveFlickr最新的原始碼已加入23HQ支援，近期內發佈新版。）
註解
- 是 Zooomr 裡面有三個 o。裡面只有兩個 o 的是個蟑螂站（不想增加他們 page rank ，就不連過去了）。嗯，這樣的命名策略很不好啊……
- Zooomr號稱以本地化語言做得好為特色（事實上23HQ也是如此）。這點表面上看來對Flickr確實有可能造成威脅──例如這一封顯然是講西班牙語的人所貼的post（只要看英文的部份就可以了），就直陳Flickr沒有西語介面的種種不是，Flickr則說，localization不是那麼容易的事。以我簡單晃了一下23HQ和Zooomr的中文介面的感覺（唔，Zooomr我順便也逛了法文和日文的），呃… 我覺得他們能先把「一兩種語言」做好，就應該要覺得滿足了吧。
lukhnos :: Jan.09.2007 :: tekhnologia 技術或者藝術 :: No Comments »