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

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

 A. 為所有“事物”定義ID
 B. 將所有事物鏈接在一起
 C. 使用標準方法
 D. 資源多重表述
 E. 無狀態通信

讀完后有下列疑問：

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

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

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

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

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

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

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

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

進一步地引申到實現問題？假如為這么多事物引入ID，那么會不會導致我們的存儲結構暴增？在上面這篇文章中也提到了這樣的觀點：

C. 使用鏈接指向任何可以標識的事物

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

D. “標準方法”是否夠用？

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

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

E. 無狀態通信如何實現

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

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

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