摘要：其他交互一般會(huì)遵循一些數(shù)據(jù)結(jié)構(gòu)協(xié)議或者狀態(tài)值，比如不同的操作結(jié)果對(duì)應(yīng)不同的狀態(tài)值，且出錯(cuò)會(huì)返回指定的錯(cuò)誤信息方便前端進(jìn)行提示等。

RESTful這種架構(gòu)已經(jīng)具有很長(zhǎng)的時(shí)間和歷程了，但似乎最近restful這個(gè)詞出現(xiàn)的頻率特別高，目前不是很清楚是因?yàn)槲易詡€(gè)兒現(xiàn)在是以restful風(fēng)格寫程序產(chǎn)生的孕婦效應(yīng)，還是單頁(yè)面程序開發(fā)的流行造成的。

其實(shí)一開始我也是不想寫這篇文章的，因?yàn)榫W(wǎng)絡(luò)上與restful相關(guān)的文章挺多，而且都寫得挺好的，都具有比較高的參考價(jià)值。但是我仔細(xì)梳理了我所看過(guò)的文章，發(fā)現(xiàn)大家基本上講的是restful的理論經(jīng)驗(yàn)，好像并沒(méi)有過(guò)多的提及restful實(shí)際程序設(shè)計(jì)上的一些經(jīng)驗(yàn)總結(jié)。而且關(guān)于這方面的經(jīng)驗(yàn)總結(jié)我曾經(jīng)也想找找來(lái)做參考也并沒(méi)有找到，因此，我寫這篇文章，希望一些人能得到一些參考（因?yàn)槭俏覀€(gè)人實(shí)踐，可能有些不符合大流的地方，那就請(qǐng)多多包涵或者指出來(lái)了）。

另外這篇文章我不會(huì)去講一些底層restful支持怎么設(shè)計(jì)（restful框架怎么設(shè)計(jì)），要說(shuō)這個(gè)的話，那么內(nèi)容太長(zhǎng)了，我主要講應(yīng)用層面的東西，也就是具體業(yè)務(wù)邏輯的一些東西，當(dāng)然會(huì)做一些基本的引申講解。

說(shuō)到restful就不得不說(shuō)資源這個(gè)東西了，restful的每一個(gè)接口所對(duì)應(yīng)的應(yīng)該是一個(gè)資源。那么，在restful里面，“資源”這個(gè)詞其實(shí)應(yīng)該算是一個(gè)抽象概念了，這個(gè)“資源”所包含的資源就不僅僅是常規(guī)意義上的資源了。我覺(jué)得換一種方式叫法，把這種資源叫做對(duì)象，可能會(huì)更加方便理解。

當(dāng)然，首先我們其實(shí)應(yīng)該說(shuō)一下什么是資源。資源包含的東西很多，從圖片到音頻、視頻等數(shù)據(jù)，以及文本等都是資源。也就是說(shuō)，服務(wù)器上存在的數(shù)據(jù)就是資源。

但是，多帶帶說(shuō)資源沒(méi)有太多意義，應(yīng)該說(shuō)資源的表現(xiàn)方式才有意義，或者說(shuō)數(shù)據(jù)的表現(xiàn)方式才有意義，此處挺重要的，這個(gè)涉及到后續(xù)我說(shuō)的restful風(fēng)格設(shè)計(jì)方面的東西。通常來(lái)說(shuō)，我們打開一個(gè)URL所能看到的就是一個(gè)完整的html界面，而其實(shí)，這個(gè)html界面就是資源，html所顯示出來(lái)的圖片、音頻、視頻等等都是資源。說(shuō)到這里可能有些人在做開發(fā)過(guò)程中對(duì)于一些東西具有誤解，認(rèn)為restful風(fēng)格所獲取的資源是服務(wù)端返回json數(shù)據(jù)。關(guān)于這個(gè)，我們應(yīng)該搞清楚幾個(gè)概念：

數(shù)據(jù)類型：就是服務(wù)端返回的數(shù)據(jù)類型，如html、圖片、視頻、Excel表格、world文檔等等；
傳輸方式：異步和同步；
串行和并行傳輸： 串行傳輸是等一個(gè)數(shù)據(jù)傳輸完成再傳輸另外一個(gè)數(shù)據(jù)，并行是同時(shí)執(zhí)行。

這三個(gè)東西我就不展開細(xì)說(shuō)了，說(shuō)起來(lái)比較復(fù)雜，我就說(shuō)一下串行和并行與異步和同步的一個(gè)大致講解就好了，很多人覺(jué)得異步是并行執(zhí)行的，或者說(shuō)把異步理解成并行執(zhí)行的，這其實(shí)不一定，異步只能說(shuō)執(zhí)行的時(shí)候在某個(gè)流程執(zhí)行的時(shí)候可以開始其他任務(wù)執(zhí)行，減少阻塞。

常用的請(qǐng)求方式大致就是：GET、POST、PUT、DELETE、OPTIONS。

GET：接口從字面意識(shí)理解，就是獲取數(shù)據(jù)的，而我們?cè)谠O(shè)計(jì)的時(shí)候，GET應(yīng)該是包含兩種數(shù)據(jù)獲取方式，一種是獲取整體數(shù)據(jù)列表，一種是根據(jù)指定ID獲取數(shù)據(jù)。

POST：是新增數(shù)據(jù)用的，此請(qǐng)求方式設(shè)計(jì)的接口是新增數(shù)據(jù)；

PUT：是修改數(shù)據(jù)接口，如果要對(duì)資源做數(shù)據(jù)修改，那么程序應(yīng)該考慮放在這個(gè)接口中；

DELETE：很容易理解，這個(gè)請(qǐng)求方式對(duì)應(yīng)的是對(duì)接口的刪除操作；

OPTIONS：這個(gè)接口蠻有意思的，通常這個(gè)接口設(shè)計(jì)為返回當(dāng)前接口的一些信息，比如有哪些字段，哪些字段允許請(qǐng)求哪些字段不允許等。

那么后端的業(yè)務(wù)邏輯程序應(yīng)該向外提供基本的五個(gè)接口，如：

interface Api {
    public function index() {} // GET 列表接口 /api
    public function view() {} // GET 單個(gè)數(shù)據(jù)接口 /api/:id
    public function create() {} // POST 創(chuàng)建接口 /api
    public function update() {} // PUT 修改接口 /api/:id
    public function delete() {} // DELETE 刪除接口 /api/:id
}

嗯，說(shuō)了以上一大堆，那么這個(gè)點(diǎn)估計(jì)才是比較關(guān)鍵的東西。

可以看以上的那段代碼接口，我后面的注釋做了請(qǐng)求方式和功能性說(shuō)明，來(lái)看一下update這個(gè)接口，這個(gè)接口需要注意的是，通常設(shè)計(jì)的修改接口后面必須要帶上指定的數(shù)據(jù)id，這里的:id指的是資源id參數(shù)。從這里來(lái)看，似乎對(duì)于資源的修改具有一定的局限性，當(dāng)然刪除也如此。然后，我想很多人應(yīng)該就開始有一個(gè)疑問(wèn)了：“臥槽，老子要做批量修改，咋辦？這restful也太局限了吧？”。

對(duì)，我開始就是這么想的，后來(lái)經(jīng)過(guò)我的思考，我發(fā)現(xiàn)并不是這樣。我上文提到，服務(wù)端任何數(shù)據(jù)都是資源，而且資源在restful里應(yīng)該算是一個(gè)抽象的意義。上文沒(méi)法做說(shuō)明，但其實(shí)，這個(gè)是關(guān)乎到程序設(shè)計(jì)上的一些問(wèn)題的。

首先，我們來(lái)假設(shè)有這樣一個(gè)例子，我們要批量刪除一堆商品數(shù)據(jù)。按照傳統(tǒng)的思維，用戶批量選擇，然后把這一堆id傳遞到后端，然后后端根據(jù)這一批id來(lái)進(jìn)行刪除。我說(shuō)這個(gè)，并不是要表達(dá)在restful里這套思維行不通，首先應(yīng)該肯定這是對(duì)的，但是，我們要做的是跳出這期間設(shè)計(jì)到的另外一個(gè)思維。也就是此時(shí)我們把商品當(dāng)做一個(gè)資源操作，此時(shí)，我們應(yīng)該把“刪除商品”當(dāng)做一個(gè)資源，而不是商品。那么我們?cè)谠O(shè)計(jì)接口的時(shí)候，就具有非常大的意義了。我們把“刪除商品”當(dāng)做一個(gè)資源，暫且把這個(gè)接口定義為：/delete-goods。那么，刪除就是對(duì)應(yīng)的post接口，也就是創(chuàng)建“刪除商品”，那么撤銷刪除可以對(duì)應(yīng)delete接口，也就是刪除“刪除商品”。

以上描述得可能有些拗口，但實(shí)際上就是這樣，如果這么設(shè)計(jì)，我們遵循了restful的標(biāo)準(zhǔn)，其實(shí)交互流程與傳統(tǒng)沒(méi)有太多差別，唯一的差別就是思想的轉(zhuǎn)換。分析以上，其實(shí)我們應(yīng)該得出一些結(jié)論：

做restful設(shè)計(jì)的時(shí)候，程序設(shè)計(jì)思維應(yīng)該要做一定的轉(zhuǎn)換，在不同的場(chǎng)景思考到底什么才應(yīng)該是資源，應(yīng)該把什么當(dāng)做資源？

做restful應(yīng)該把邏輯拆分得更清晰，沒(méi)個(gè)邏輯對(duì)象只做五件事情：看列表數(shù)據(jù)、看單個(gè)數(shù)據(jù)、增加數(shù)據(jù)、修改數(shù)據(jù)、刪除數(shù)據(jù)。

以上我雖然是就刪除來(lái)說(shuō)的，其實(shí)批量修改等也貼合這種思想，也包括我之前回答的一個(gè)問(wèn)題，就是批量閱讀消息這種操作也貼合于這種思想。

restful交互一般會(huì)遵循一些數(shù)據(jù)結(jié)構(gòu)協(xié)議或者HTTP狀態(tài)值，比如不同的操作結(jié)果對(duì)應(yīng)不同的HTTP狀態(tài)值，且出錯(cuò)會(huì)返回指定的錯(cuò)誤信息方便前端進(jìn)行提示等。

當(dāng)然restful接口的設(shè)計(jì)為了完全遵循自然語(yǔ)義也可以采用請(qǐng)求資源列表采用復(fù)數(shù)請(qǐng)求方式（語(yǔ)言中的單數(shù)詞和復(fù)數(shù)詞）等等。

不管怎么變化，我覺(jué)得最基本的還是不同的請(qǐng)求方式對(duì)應(yīng)的不同操作問(wèn)題，所有的操作對(duì)應(yīng)的還是同一個(gè)接口。

以上就是我的一些應(yīng)用場(chǎng)景的理解和總結(jié)，歡迎大家一起交流。