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