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