轉自：http://blog.csdn.net/yanical/article/details/7856670
Rest的作者認為計算機發展到現在，最大的成就不是企業應用，而是web，是漫漫無邊的互聯網web世界。Web能有這么大的成就，它值得我們研究。所以Rest的作者仔細研究了Web，按照Web的世界一些關鍵特性，提出了我們在實現企業應用的時候應該遵循的一種風格，就是Restful。
Rest風格的API可以給我們很多好處，比如：簡潔，統一，性能，可擴展性等等。可惜的是，在實現Rest的時候，總有一些Rest的關鍵特性沒有實現，比如，無狀態性，這在我做過的兩個項目和我知道的另外一個項目都存在。事實上要實現無狀態性在Java里不是那么容易，因為那意味着要把servlet的session拋棄了。除此之外，Rest的一些其他特性在各個項目中實現的也是各有不同。
接下來，我會列出一些我認為的，要實現Rest風格API的關鍵步驟：
1. 所有東西都是資源（Resource）
所有要給API操作的對象都只能是資源。不管實際上存在的，還是抽象上的。所有資源都會有一個不變的標識（ID），對資源的任何API操作都不應該改變資源的標識。資源和其他資源會有關系，資源與資源的關系通過資源的標識來引用。對資源的操作都應該是完整的，比如獲取資源拿到的應該是一個完整的資源對象（根據企業引用特點有些例外，后面會提到）。
事實上，上面的這些完完全全是按照互聯網的特性提出來的。互聯網中，一個URL就是一個資源；資源的內容就是HTML頁面；不管怎么改HTML內容，URL都不會改變；資源之間通過HTML里的連接聯系起來；每次獲取的時候，獲取到的都是完整的HTML內容。
假設有一個博客系統，那么其中的資源可以包括：博主，每個博主都是一個資源；博客，每篇博客都是一個資源，博客和博主之間有聯系，通過ID聯系起來；每篇博客都會有回復，回復也算是資源，但是它是隸屬於博客的，可以認為回復是博客的子資源（你也可以認為博客是博主的子資源，怎么抽象取決於具體的應用，這里不討論）。
這步通常不難實現，因為這和ORM中的對象概念是類似的，實現上，如果用了hibernate之類的框架，改動也應該很小。
2. 規范對資源的操作，最好只包括CRUD
CRUD指創建（Create），讀取（Read）， 更新（Update），刪除（Delete）
通常對資源的操作只包含CRUD是不可能的，CRUD里甚至連查找的操作的都沒有。但這不妨礙我們對Rest的理解，Rest提出的要求是，對資源的操作都應該是統一的，不管是操作哪種類型的資源，API都應該是一致的。這樣當調用API的客戶端知道某種資源的時候，它不需要去學習對這個資源該怎么操作，因為對所有資源的操作都是一致的，它們都應該支持CRUD操作，以及一些其他操作，比如list（用來查找，或者列出所有資源）， merge（部分更新資源，這應該是唯一的不操作資源所有內容的API）。
這和Web也是一樣的，HTTP里只有GET，PUT，POST，HEAD等等幾個統一的請求（參考：http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html）。
要實現簡單的幾個操作不難，難在這幾個簡單操作沒法支撐整個系統的需求。但是想想吧，互聯網也夠復雜了吧，還是不是成功了，而且魚和熊掌不可兼得。有時候服務器端也不一定要實現所有東西，可以把一些邏輯交給客戶端去做。比如顯示，Rest里顯示是完全交給客戶端去處理的，服務器只管數據的存儲，不管客戶端是網頁，還是一個手機應用程序，還是另外一個企業應用。各種各樣的客戶端進來，他們會有各種各樣的需求，服務器端不可能一一滿足，只能客戶端使用統一的API去組合，實現自己的需求。
3. 規范URL的使用
好了，對資源的操作統一了，但是客戶端還是要知道怎么觸發對資源的某個具體的操作。Rest用URL的規范來保證這種統一性。
創建並保存一個博客：
- POST /blog/save
這個請求需要返回博客的保存后的結果，其中包括博客的標識（ID）。 獲取一個已經保存的博客，並更新它：
- GET /blog/get/345
- //更新它
- POST /blog/update/345
這個博客的標識是345。獲取博客的某個回復：
- GET /blog/get/345/reply/456
對待子資源，通常的做法就是和這個例子一樣，是一級一級的往下找。我們還可以有其他方法，比如remove用來刪除，merge用來部分更新，list用來查找。
有三種方式可以將參數傳給API操作：
第一種是通過URL的地址傳遞，如前面的例子中把標識放在URL里；
第二種是通過URL的參數，比如，對於一個查找請求，可以把查找的過濾條件放在參數里：
- GET /blog/list?name=Azure：用InstanceInputEndpoint直接和指定instance通信
第三種是PUT或者POST請求的時候，把內容放在HTTP body里面。這里通常就是博客的內容。
前面我們的例子中有些請求是GET，有些是POST，其實這是有原則的。通常對資源內容沒有改變的操作都實用GET，比如獲取資源，查找資源；對資源有改變的操作都用POST，比如保存資源。
如果想做的更好，我們應該近一步的使用HTTP的請求方法，直接把HTTP方法和要做的操作映射起來。比如我喜歡認為GET請求就是獲取資源（get），PUT方法就是更新整個內容（save，update，我覺得這兩個沒必要區分），POST方法就是更新部分內容（merge），DELETE方法就是刪除資源（remove）。如果這樣的話，請求的URL又能簡化：
- PUT /blog //創建保存一個新的博客
- GET /blog/345 //獲取博客345內容
- PUT /blog/345 //更新博客345
- GET /blog/345/reply/456 //獲取博客345的回復456
- POST /blog/345 //更新博客345的部分內容
- DELETE /blog/345 //刪除博客345
當然對於list操作，這里就沒法滿足了，還是需要在URL層面上做些區別。
對於merge操作，有很多人認為是不必要的，Rest不應該提供這個API，但是我覺得在某些情況下很有用。比如某個資源對象，它的內容在不斷的擴充，怎么讓老的客戶端在內容擴充后還能繼續使用呢？ 如果我們要求所有更新請求都必須把所有內容都放在請求的body中，對於客戶端來說就不是那么好做了，但是如果我們允許merge請求，客戶端可以可以完全忽略新增加的字段，而只把自己知道的字段放在請求內容中即可。
4. 資源的多重表述
這一步我覺得不是必須的。
Rest里，資源的內容通常直接作為一段JSON或者XML返回給客戶端。資源多重表述指的是，一個資源應該能夠支持根據客戶端的請求，返回相應的格式給客戶端。服務器應該按照請求HTTP頭中的Accept屬性決定返回格式。比如對於Ajax請求，Accept頭是application/json，服務端返回JSON格式；對於Android請求，Accept頭是application/xhtml+xml，服務器返回XML格式。
我覺得這一步不是必須的因為至少從項目前期來說，我們應該都只會支持一種格式。資源的多重表述給我們一種處理多重請求格式的方式，但是我們不需要一開始就支持它。
5. 進一步合理利用HTTP
前面我們已經應用了HTTP的一些東西，比如請求方法，Accept頭。事實上我們可以利用更多。
HTTP支持客戶端緩存，在HTTP響應里利用Cache-Control，Expires，Last-Modified三個頭字段，我們可以讓瀏覽器緩存資源一段時間。Rest也可以利用這些頭，告訴客戶端在一定時間內不需要再次請求資源。這對提高性能有很大好處。更多HTTP頭信息，可以參考http://en.wikipedia.org/wiki/List_of_HTTP_header_fields。
Rest的請求會出錯，HTTP的請求也會出錯。我們可以直接利用HTTP的response code來告訴客戶端Rest請求出了什么錯誤。比如500，告訴客戶端，服務器出錯了；401告訴客戶端需要把安全驗證信息附上，需要登錄系統；404告訴請求的資源不存在，等等。更多HTTP響應碼，可以參考http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html。在實際的業務中，HTTP的那些response code肯定是不能滿足所有需求的，適當的在response body中加上更詳細的錯誤信息也是必須的。
還有其他很多，總之能利用上的就利用上，不比再次發明輪子。
6. 實現請求的無狀態
Rest是無狀態的。Rest的請求之間不應該有依賴，在調用一個請求前，不需要一定要去提前調用另外一個請求。Rest里面不應該有session，特別是Rest請求不應該保存信息在sesssion里，以便在后面的調用中使用。甚至包括安全驗證，客戶端不應該需要提前登錄，然后把權限信息保存在session里，后面的請求用同一個session來調用。
實現無狀態的方法就是，把所有信息都包含在當前的請求中，包括驗證信息。HTTP是無狀態的，HTTP里有一個Authorization頭，HTTP的要求是在每次請求的時候都把驗證信息放在里面，服務器每次處理請求前都去驗證這個信息。為了安全，我們可以提供一個生成token的Rest API，客戶端調用這個API生成token（可以附上用戶名/密碼來生成token）。在后面的所有請求中都把這個token放在Authentication頭中。
實現無狀態最大的好處是能夠方便的擴展服務器，也即scalability。否則的話，我們要么把Session綁定到具體服務器上，要么用一個共享的空間存儲Session。而實現無狀態后，我們可以隨意增加，減少服務器數量，都不會對當前用戶造成影響。