REST on Rails指南2：無窮盡的API

通過上一講，我認為你樹立了這個概念：即Web其實是一組資源而不是網頁的集合（如果你還不這麼認為，那請你先傳回再次閱讀第一講）。這一講我們将從另一個側面來講解為什麼要有REST？

面向對象設計與分析

如果你曾經學習過面向對象程式設計，那麼你很可能會這樣開始建構你的新程式：

• 首先，你需要定義你的問題域——你的程式要解決什麼問題
• 然後，你會定義一個類，這個類的名字一般是名詞
• 接着你會為這個類定義一些方法，方法的名字一般是動詞
• 最用，通過調用其它類的方法，你的這個類順利完成了它的使命

這看起來不錯，事實上我曾經這麼幹了好多年，這種名詞加動詞的程式設計方法被成為“RPC”（遠端過程調用），雖然我不明白那個Remote（遠端）是指什麼，但RPC的确是建構面向對象軟體的一個重要方法，不過這種方式卻并不适合Web開發。

讓我們回到遠古，假設現在是1992年（或者Web出現之前的随便什麼日子），假設有這樣的三家公司，他們需要開發這樣三種應用：書籍販賣，機票販賣以及 衛星地圖浏覽。并且他們都遵照了面向對象的設計思想，同時出于長遠考慮，他們都認為總有一天會有第三方的軟體需要同他們的系統進行互動，是以，他們都實作 了他們各自的API。

現在，假設你的老闆配置設定給你一個任務：為這三個系統設計一個統一的前端，你會怎麼做呢？

我想你首先需要學習這三種完全不同的API，然後為每一個API設計一個UI控件，當使用者操作UI控件時，對應的API就會被調用，你可能會通過你學到的一些設計模式知識來簡化你的工作量，并使你的代碼看起來盡可能酷一些。

無窮盡的API

當然這隻是假設，但即使真的如此，在Web時代，你也不需要去學習那些無窮盡的糟糕API，你所要做的就是在你的電腦上安裝一個浏覽器，不是嗎？浏覽器對 于你将要通路的網站一無所知，但它卻能夠準确的傳回你想要的，你可以通過它購買音樂，預定機票，甚至從任意遠的距離來欣賞你家的屋頂。

這很神奇，不是嗎？但是讓我們設想一下，如果每個網站都有它們自己的API會是什麼樣子？如果你想在Amazon買本書，浏覽器必須知道如何調用 Amazong.buy()，如果你想檢視航班資訊，那麼浏覽器需要知道如何調用UnitedAirlines.CheckFlights()，事實上， 這樣通吃所有API的程式永遠也不可能被開發出來。

是以這就決定了Web不可能是RPC式的，它隻能是REST式的。

以資源為中心的設計

那麼REST究竟是什麼呢？按照維基百科的解釋，REST是指Representational State Transfer。這是什麼意思呢，簡單的說，就是現在每個名詞都不再擁有它們各自獨一無二的動詞了，在REST的世界裡，所有名詞擁有的動詞都是一樣 的，并且數量也很有限。換句話說，也就是所有的資源都提供了一組相同的API，這些API的實質就是允許随便什麼用戶端：

• 擷取資源的某種表示
• 建立一個新資源
• 更新已存在的資源
• 銷毀一個資源

等一下！那麼究竟上面那個API可以讓我“購買一本書”呢？搜尋“下周二從紐約飛往洛杉矶的航班”又是哪個API完成的呢？

我們将在下一講回答這個問題，但是如果你已經改變思維，不再認為”買書“就是一個網頁，而是開始思考這其實是某個資源的建立，那麼我想你其實應該已經知道答案了。