RESTful實踐（具體應用）思考

RESTful這種架構已經具備很長的時間和歷程了，但彷佛最近restful這個詞出現的頻率特別高，目前不是很清楚是由於我自個兒如今是以restful風格寫程序產生的孕婦效應，仍是單頁面程序開發的流行形成的。

其實一開始我也是不想寫這篇文章的，由於網絡上與restful相關的文章挺多，並且都寫得挺好的，都具備比較高的參考價值。可是我仔細梳理了我所看過的文章，發現你們基本上講的是restful的理論經驗，好像並無過多的說起restful實際程序設計上的一些經驗總結。並且關於這方面的經驗總結我曾經也想找找來作參考也並無找到，所以，我寫這篇文章，但願一些人能獲得一些參考（由於是我我的實踐，可能有些不符合大流的地方，那就請多多包涵或者指出來了）。

另外這篇文章我不會去講一些底層restful支持怎麼設計（restful框架怎麼設計），要說這個的話，那麼內容太長了，我主要講應用層面的東西，也就是具體業務邏輯的一些東西，固然會作一些基本的引伸講解。

資源

說到restful就不得不說資源這個東西了，restful的每個接口所對應的應該是一個資源。那麼，在restful裏面，「資源」這個詞其實應該算是一個抽象概念了，這個「資源」所包含的資源就不只僅是常規意義上的資源了。我以爲換一種方式叫法，把這種資源叫作對象，可能會更加方便理解。

固然，首先咱們其實應該說一下什麼是資源。資源包含的東西不少，從圖片到音頻、視頻等數據，以及文本等都是資源。也就是說，服務器上存在的數據就是資源。

可是，單獨說資源沒有太多意義，應該說資源的表現方式纔有意義，或者說數據的表現方式纔有意義，此處挺重要的，這個涉及到後續我說的restful風格設計方面的東西。一般來講，咱們打開一個URL所能看到的就是一個完整的html界面，而其實，這個html界面就是資源，html所顯示出來的圖片、音頻、視頻等等都是資源。說到這裏可能有些人在作開發過程當中對於一些東西具備誤解，認爲restful風格所獲取的資源是服務端返回json數據。關於這個，咱們應該搞清楚幾個概念：

1. 數據類型：就是服務端返回的數據類型，如html、圖片、視頻、Excel表格、world文檔等等；
2. 傳輸方式：異步和同步；
3. 串行和並行傳輸： 串行傳輸是等一個數據傳輸完成再傳輸另一個數據，並行是同時執行。

這三個東西我就不展開細說了，提及來比較複雜，我就說一下串行和並行與異步和同步的一個大體講解就行了，不少人以爲異步是並行執行的，或者說把異步理解成並行執行的，這其實不必定，異步只能說執行的時候在某個流程執行的時候能夠開始其餘任務執行，減小阻塞。

請求方式

經常使用的請求方式大體就是：GET、POST、PUT、DELETE、OPTIONS。

GET：接口從字面意識理解，就是獲取數據的，而咱們在設計的時候，GET應該是包含兩種數據獲取方式，一種是獲取總體數據列表，一種是根據指定ID獲取數據。

POST：是新增數據用的，此請求方式設計的接口是新增數據；

PUT：是修改數據接口，若是要對資源作數據修改，那麼程序應該考慮放在這個接口中；

DELETE：很容易理解，這個請求方式對應的是對接口的刪除操做；

OPTIONS：這個接口蠻有意思的，一般這個接口設計爲返回當前接口的一些信息，好比有哪些字段，哪些字段容許請求哪些字段不容許等。

那麼後端的業務邏輯程序應該向外提供基本的五個接口，如：

interface Api {
    public function index() {} // GET 列表接口 /api
    public function view() {} // GET 單個數據接口 /api/:id
    public function create() {} // POST 建立接口 /api
    public function update() {} // PUT 修改接口 /api/:id
    public function delete() {} // DELETE 刪除接口 /api/:id
}

業務邏輯設計思惟方向

嗯，說了以上一大堆，那麼這個點估計纔是比較關鍵的東西。

能夠看以上的那段代碼接口，我後面的註釋作了請求方式和功能性說明，來看一下update這個接口，這個接口須要注意的是，一般設計的修改接口後面必需要帶上指定的數據id，這裏的:id指的是資源id參數。從這裏來看，彷佛對於資源的修改具備必定的侷限性，固然刪除也如此。而後，我想不少人應該就開始有一個疑問了：「臥槽，老子要作批量修改，咋辦？這restful也太侷限了吧？」。

對，我開始就是這麼想的，後來通過個人思考，我發現並非這樣。我上文提到，服務端任何數據都是資源，並且資源在restful裏應該算是一個抽象的意義。上文無法作說明，但其實，這個是關乎到程序設計上的一些問題的。

首先，咱們來假設有這樣一個例子，咱們要批量刪除一堆商品數據。按照傳統的思惟，用戶批量選擇，而後把這一堆id傳遞到後端，而後後端根據這一批id來進行刪除。我說這個，並非要表達在restful裏這套思惟行不通，首先應該確定這是對的，可是，咱們要作的是跳出這期間設計到的另一個思惟。也就是此時咱們把商品當作一個資源操做，此時，咱們應該把「刪除商品」當作一個資源，而不是商品。那麼咱們在設計接口的時候，就具備很是大的意義了。咱們把「刪除商品」當作一個資源，暫且把這個接口定義爲：/delete-goods。那麼，刪除就是對應的post接口，也就是建立「刪除商品」，那麼撤銷刪除能夠對應delete接口，也就是刪除「刪除商品」。

以上描述得可能有些拗口，但實際上就是這樣，若是這麼設計，咱們遵循了restful的標準，其實交互流程與傳統沒有太多差異，惟一的差異就是思想的轉換。分析以上，其實咱們應該得出一些結論：

1. 作restful設計的時候，程序設計思惟應該要作必定的轉換，在不一樣的場景思考到底什麼才應該是資源，應該把什麼當作資源？
2. 作restful應該把邏輯拆分得更清晰，沒個邏輯對象只作五件事情：看列表數據、看單個數據、增長數據、修改數據、刪除數據。

以上我雖然是就刪除來講的，其實批量修改等也貼合這種思想，也包括我以前回答的一個問題，就是批量閱讀消息這種操做也貼合於這種思想。

其餘

restful交互通常會遵循一些數據結構協議或者HTTP狀態值，好比不一樣的操做結果對應不一樣的HTTP狀態值，且出錯會返回指定的錯誤信息方便前端進行提示等。

固然restful接口的設計爲了徹底遵循天然語義也能夠採用請求資源列表採用複數請求方式（語言中的單數詞和複數詞）等等。

無論怎麼變化，我以爲最基本的仍是不一樣的請求方式對應的不一樣操做問題，全部的操做對應的仍是同一個接口。

以上就是個人一些應用場景的理解和總結，歡迎你們一塊兒交流。