REST手記(一)：對(duì)URI隧道技術(shù)以及CRUD操作的理解

　　近來(lái)看了Jim Webber等REST實(shí)戰(zhàn)，有一些體會(huì)，因此對(duì)一些概念做個(gè)簡(jiǎn)要的整理。以下是個(gè)人認(rèn)識(shí)與理解，如有偏差，望指正。

• 1、URI隧道技術(shù)。

　　通過(guò)URI來(lái)進(jìn)行跨越系統(tǒng)邊界轉(zhuǎn)移信息的一種方式。它是通過(guò)將信息編碼到URI中。如：http://www.taobao.com/PlaceOrder?size={xx}&type={xx}&color={xx}這是一種有效的方法。因?yàn)闊o(wú)論在Server端還是Client端，它都容易被理解。但是在一般情況下，URI隧道技術(shù)并非是Web友好的。因?yàn)樗鼪](méi)有描述對(duì)資源進(jìn)行操作的方式、以及操作資源時(shí)使用的元數(shù)據(jù)。如果有消費(fèi)者使用Get操作來(lái)操作以上URI而產(chǎn)生資源，那么就完全違背了Web的架構(gòu)原則。

• 2、CRUD的WebService。

　　在說(shuō)到CRUD之前，先說(shuō)說(shuō)冪等。
　　冪等是數(shù)學(xué)上的概念。無(wú)論操作操作多少次，這次操作產(chǎn)生的結(jié)果都是一樣的。比如：數(shù)學(xué)中的計(jì)算絕對(duì)值。

　　2.1 C:Create。
　　Create 資源通過(guò)HTTP POST動(dòng)作創(chuàng)建。POST在HTTP協(xié)議中就被設(shè)計(jì)為不安全、不冪等。為什么說(shuō)它不安全？因?yàn)橄M(fèi)者將信息POST到服務(wù)中，服務(wù)就需要為客戶(hù)端創(chuàng)建資源。這樣就有可能改變服務(wù)端資源的多少、組織形式等等。為什么說(shuō)它不冪等呢？
因?yàn)楦鶕?jù)HTTP協(xié)議的規(guī)范，POST信息到服務(wù)端后，服務(wù)端就需要?jiǎng)?chuàng)建資源。一次POST就創(chuàng)建一個(gè)新的資源，即使消費(fèi)者每次提交的信息完全一致。

　　2.2  R：Read。
　　Read讀取資源。通過(guò)HTTP GET操作獲取。即安全又冪等。因?yàn)樗啻潍@取資源，但是不會(huì)對(duì)資源的狀態(tài)進(jìn)行操作，所以說(shuō)它是安全的。
　　也許有人會(huì)說(shuō)，如博客園獲取48小時(shí)閱讀排行，那按照冪等的說(shuō)法就應(yīng)該每次都獲取一樣的信息，而不會(huì)有更新出現(xiàn)。是的，你這種說(shuō)法沒(méi)錯(cuò)。如果每次獲取資源都一樣那就應(yīng)該不會(huì)更新。這里所說(shuō)的冪等指的是這類(lèi)資源的性質(zhì)是一致的。而不是說(shuō)資源的表述每次都應(yīng)該一樣。

　　2.3 U：Update。
　　PUT 操作進(jìn)行資源的更新。它冪等但是不安全。冪等表現(xiàn)在它對(duì)資源的多次操作，最終在服務(wù)端，按照HTTP標(biāo)準(zhǔn)，應(yīng)該用客戶(hù)端上傳過(guò)來(lái)的信息完全替換掉服務(wù)端相應(yīng)的資源。因?yàn)檫@可能導(dǎo)致服務(wù)端資源狀態(tài)發(fā)生變更，所以它不安全。
　　PUT 操作完成以后，返回給客戶(hù)端一個(gè)200相應(yīng)消息的詳細(xì)描述或者204 no content 信息。但后者由于相應(yīng)信息少，因此效率更高。當(dāng)然在最新的IETF Internet標(biāo)準(zhǔn)中新增了PATCH動(dòng)詞，但是PATCH是對(duì)部分資源發(fā)送補(bǔ)丁信息，服務(wù)端針對(duì)這些信息對(duì)資源進(jìn)行部分更新。

　　2.4 D：DELETE.
　　DELETE刪除資源。與Update操作一樣，冪等但是不安全。注意：這里的DELETE不一定是真要是服務(wù)端刪除某一資源，只是表明REST某一客戶(hù)端對(duì)這一資源已經(jīng)不再關(guān)心，但是這些資源可能會(huì)被其他客戶(hù)端所用到。

• 3、校正資源狀態(tài)。

　　在分布式系統(tǒng)應(yīng)用中，經(jīng)常出現(xiàn)多個(gè)消費(fèi)者與一個(gè)資源交互的應(yīng)用場(chǎng)景。這樣就有可能導(dǎo)致一個(gè)問(wèn)題的發(fā)生。比如：一個(gè)用戶(hù)對(duì)資源進(jìn)行操作而改變了它的狀態(tài)，而另一消費(fèi)者沒(méi)有通過(guò)Get獲取到最新?tīng)顟B(tài)，同樣去操作這一資源就不會(huì)得到想要的結(jié)果。
　　HTTP提供了一種簡(jiǎn)單但是強(qiáng)大的機(jī)制來(lái)解決這個(gè)問(wèn)題。那就是通過(guò)實(shí)體標(biāo)簽（Entity Tag）與條件請(qǐng)求頭(Conditional Request Header)If-Match或If-None-Match的形式，對(duì)所請(qǐng)求的資源進(jìn)行校正。一個(gè)實(shí)體標(biāo)簽就是一個(gè)不透明的令牌，使服務(wù)端與資源關(guān)聯(lián)起來(lái)，以便在資源的生命周期中唯一?？梢酝ㄟ^(guò)Hash算法來(lái)指定ETag值。
　　If-Match或If-None-Match很好理解，如果匹配則如何，如果不匹配又如何處理。
　　通常If-Match:"*",來(lái)指明資源存在，If-None-Match:"*"則指明資源不存在。
　　篇幅有限，這節(jié)就這么多了。希望對(duì)你理解REST有些幫助。
　　下一節(jié)將介紹：超媒體服務(wù)、以及相關(guān)的一些概念知識(shí)點(diǎn)。