InfoQ上有一篇《深入淺出REST》的文章：http://www.infoq.com/cn/articles/rest-introduction

文章中的主要觀點包括了：

 A. 為所有“事物”定義ID
 B. 將所有事物鏈接在一起
 C. 使用標(biāo)準(zhǔn)方法
 D. 資源多重表述
 E. 無狀態(tài)通信

讀完后有下列疑問：

A. 觀點1中這個“ID”如何定義？

文章中提到了使用URI作為所有“事物(資源)” 的唯一ID，于是為了這樣一個疑問：為什么不能用URL，而用URI呢？網(wǎng)上對URI和URL的區(qū)別并沒有一個明確的說服，我個人的理解是這樣的：

URI是資源標(biāo)識符，而URL是資源定位器。假設(shè)我們對所有的資源都進(jìn)行統(tǒng)一標(biāo)識(注意是全局唯一標(biāo)識)，有一個資源的標(biāo)記是4321，那么這個4321是URI。而如何獲取到這個4321資源呢？URI并沒有說明。于是我們可以同HTTP協(xié)議，或者FTP協(xié)議來獲取，這種依賴于特定通訊協(xié)議的獲取方式就是URL了。

但是不管是URI還是URL，只要指向同一個資源，最終都是通過唯一的這個標(biāo)識(URI)來區(qū)分資源的。

不知道這個理解是否正確？

B. 要為那些“事物”定義ID？

文章中提到了我們不單為一個單一的資源定義ID，我們也可以為資源的集合定義ID。于是就有了這樣的疑問：

對于一些集合范圍比較明確的資源，比如blog的按年月日分類，我們可以簡單地使用諸如這樣的URL：http://xxx.com/archive/2010/06/24/324348.html 來表示REST風(fēng)格的資源，但是如果這個集合的范圍是模糊的，或者是靠某些條件表達(dá)式的執(zhí)行結(jié)果來限制的，比如說所有符合條件1的文章集合。那么對于這種模式的資源，REST又如何來表示呢？

進(jìn)一步地引申到實現(xiàn)問題？假如為這么多事物引入ID，那么會不會導(dǎo)致我們的存儲結(jié)構(gòu)暴增？在上面這篇文章中也提到了這樣的觀點：

C. 使用鏈接指向任何可以標(biāo)識的事物

這一點上，我看不出REST和傳統(tǒng)的的Web概念有什么明顯區(qū)別的地方？也許是我的理解不夠

D. “標(biāo)準(zhǔn)方法”是否夠用？

從文章中可以看出，REST依靠HTTP協(xié)議的動詞(get/put/delete)來描述對資源的操作，于是在我們的應(yīng)用端有了很多抽象的標(biāo)準(zhǔn)方法：getAll, delete, getById....。問題是僅僅依靠這些標(biāo)準(zhǔn)方法夠嗎？

傳統(tǒng)的WEB請求是通過在請求中附著參數(shù)信息，如XXX.jsp?參數(shù)1&參數(shù)2，如果我們采用了REST方式的URI描述，對于一些復(fù)雜的請求描述，會不會導(dǎo)致描述困難？而且對應(yīng)的服務(wù)器端方法如何定義？畢竟現(xiàn)在很多的交互網(wǎng)站都有大量的自定義查詢，僅靠幾個簡單的CRUD方法定義顯然不能滿足，那么REST是如何解決的呢？

E. 無狀態(tài)通信如何實現(xiàn)

這是最令我困惑的一個地方。原文翻譯如下：

無狀態(tài)通信是我要講到的最后一個原則。首先，需要著重強調(diào)的是，雖然REST包含無狀態(tài)性（statelessness）的觀念，但這并不是說暴露功能的應(yīng)用不能有狀態(tài)——
事實上，在大部分情況下這會導(dǎo)致整個做法沒有任何用處。REST要求狀態(tài)要么被放入資源狀態(tài)中，要么保存在客戶端上。或者換句話說，服務(wù)器端不能保持除了單次請求之外的，任何與其通信的客戶端的通信狀態(tài)。這樣做的最直接的理由就是可伸縮性—— 如果服務(wù)器需要保持客戶端狀態(tài)，那么大量的客戶端交互會嚴(yán)重影響服務(wù)器的內(nèi)存可用空間（footprint）。（注意，要做到無狀態(tài)通信往往需要需要一些重新設(shè)計——不能簡單地將一些session狀態(tài)綁縛在URI上，然后就宣稱這個應(yīng)用是RESTful。）

但除此以外，其它方面可能顯得更為重要：無狀態(tài)約束使服務(wù)器的變化對客戶端是不可見的，因為在兩次連續(xù)的請求中，客戶端并不依賴于同一臺服務(wù)器。一個客戶端從某臺服務(wù)器上收到一份包含鏈接的文檔，當(dāng)它要做一些處理時，這臺服務(wù)器宕掉了，可能是硬盤壞掉而被拿去修理，可能是軟件需要升級重啟——如果這個客戶端訪問了從這臺服務(wù)器接收的鏈接，它不會察覺到后臺的服務(wù)器已經(jīng)改變了。