一樣是在 Zite 上看到在分享要如何設計 API 的文章與影片:「Parse Developer Day Video Series: How to Design Great APIs」。
算是觀念性的分享,很多觀念很有趣... 而不可避免的,講到 naming 的時候,PHP 又被拿出來婊... (沒辦法,這個程式語言的 naming 實在太經典 XD)
幹壞事是進步最大的原動力
一樣是在 Zite 上看到在分享要如何設計 API 的文章與影片:「Parse Developer Day Video Series: How to Design Great APIs」。
算是觀念性的分享,很多觀念很有趣... 而不可避免的,講到 naming 的時候,PHP 又被拿出來婊... (沒辦法,這個程式語言的 naming 實在太經典 XD)
剛剛才看到 Nexmo 的公告,Nexmo 的 Voice API 以往只能吃文字,然後程式會發音,但現在則可以吃 WAV 或 MP3 格式的檔案直接播放了:「Nexmo’s Voice API Now Supports .wav and .mp3 Format」。
連 API 的範例都直接給出來,好像很好玩的樣子... XD
然後仔細看文件才發現 Speech 的部份是支援中文的!代碼 zh-cn 的男/女聲發音!
Twitter 宣佈兩個帳號,@64Flavors 以及 @Overflow64,這兩個帳號的 user ID 都超過 32bits 可以存放的範圍,而且每十分鐘就會發一則 tweet:「Test accounts with user IDs greater than 32 bits」。
目前 Twitter 的 user ID 還在 32bits 可以儲存的範圍內,但官方預估在今年就會超過。
而現在是八月底,官方丟出兩個帳號讓大家實際測試 XD
在「Nobel Prize Gets Official API」看到諾貝爾獎的網站提供 API,讓人存取歷年諾貝爾獎得主的資訊了 XDDD
官方的新聞稿在「Open Data about the Nobel Prize now Available」這邊,API 資訊則在「Developer Zone」這邊。
舉例來說,http://api.nobelprize.org/v1/prize.json?year=1901
可以抓出 1901 年諾貝爾獎得主的資料 (JSON 格式)。
而除了 JSON API 外,另外還在 data.nobelprize.org 提供 Linked Data 格式的資源。
資料不多,但蠻有趣的...
在 TC 上看到 Imgur 提供商業方案:「Imgur Expands Its Revenue Streams With Latest API Update, Now Ready For Commercial Use」,同時 Imgur 也更新了 API 說明頁面:「The Imgur API - General Information」。
以圖片張數與 API request 數量限制,USD$25/month 每個月可以傳 12.5k 張以及 375k API requests。換算成每天的量,大約是 4k 0.4k 張圖與 12k 次 API call。(hmmm,Komica 不知道會不會去租用...)
看起來 Imgur 裡面的情況很糟啊,居然設計出這樣的方案。如果讓我來猜國外的觀點,Imgur 應該是被定位為「圖床」而非「相本服務」?這是要賺 eBay 賣家的錢嗎?
Imgur 圖片並不是什麼便宜的 bandwidth,而是 EdgeCast 含亞洲 PoP 的 CDN,這樣發展對嗎...
今天 MOPCON 的投影片,題目「API Design Optimized for Mobile Platform」:
在變成標準前又改了一次...
從 Google Chrome 17 後,「Web Requests」從 Experimental API 變成正式的 API,有不少地方在這次轉成正式 API 後需要修改:
chrome.experimental.webRequest
都改成 chrome.webRequest
。webRequest
permission,如果有 blocking 行為則要再加上 webRequestBlocking
permission。onBeforeRequest.addListener
時需要多加上 urls
參數。expiermental
permission,不過沒拿掉不影響運作。在 Chrome Web Store 上面已經可以看到一些跟控制 Referrer 有關的延伸套件了...
Google Reader 這次改版另外一個為人詬病的問題是「變卡」,主要原因是 Google Plus。
第一個想到的解決是利用 Adblock Plus,將 http://www.google.com/reader/*
以及 https://www.google.com/reader/*
連到 https://plusone.google.com/*
的連線需求都都擋下來。但看了 Adblock Plus 的文件,不知道要怎麼設定...
後來想到的解法是自己寫 Google Chrome Extension,主要是很久沒寫都忘光了,剛好找個實際會用到的功能來寫... 主要是用到 chrome.tabs
與 chrome.experimental.webRequest
兩組 API 組合。其中後面這組 API 必須用 about:flags
打開權限才能使用。
成品在這:「google-reader-faster」,由於用到 Google Chrome 的 Experimental API 所以無法上傳到 Web Store,所以暫時先用 dev mode 把 extension 讀進來用。之後要來再研究看看 Adblock Plus 是怎麼做到的...
把 Google Plus 擋掉後用鍵盤快速鍵操作順很多 XD
Flickr 宣佈支援 OAuth Core 1.0a 了:「Flickr now Supports OAuth 1.0a」,同時也宣佈舊的 API 將在 2012 年的上半年停用。文件在「User Authentication」這邊可以看到。
另外,除了推出新的 API 以外,Flickr 也提供用舊的 token 直接取得 OAuth Core 1.0a 的 access token 的 API call:
Transition from the old Authentication API
You can exchange an old auth token from the old Authentication API, to an OAuth access token token. The process simply requires that you make an authenticated request to the flickr.auth.oauth.getAccessToken API, which will exchange the old token used to make the request, with a new OAuth access token.
Please note, that the old auth token will be deleted 24 hours after calling this API method.
這個方法讓現有的應用可以直接轉換到新的 OAuth Core 1.0a API 上,不需要再認證一次。
Linode 在「NodeBalancers - Managed Load Balancers」這邊公開了 NodeBalancer (lbass) 服務,目前在 beta 中,想要測試的人可以開 ticket 詢問。另外,API 文件也已經先公開,可以在「NodeBalancer API」這邊看到。
以 API 提供的功能看起來還算 okay,這樣就不需要自己用 Linode 提供的 IP Failover 並且在上面架 HAProxy server...
不過有些細節還是得等測試後才知道。像是 trusted IP 問題,我在「ELB 的 IP 信任問題...」有提過 EC2 的同樣問題 (前幾天用 ELB security group 解掉了)。