資訊專欄INFORMATION COLUMN
摘要：其他交互一般會遵循一些數據結構協議或者狀態值，比如不同的操作結果對應不同的狀態值，且出錯會返回指定的錯誤信息方便前端進行提示等。
RESTful這種架構已經具有很長的時間和歷程了，但似乎最近restful這個詞出現的頻率特別高，目前不是很清楚是因為我自個兒現在是以restful風格寫程序產生的孕婦效應，還是單頁面程序開發的流行造成的。
其實一開始我也是不想寫這篇文章的，因為網絡上與restful相關的文章挺多，而且都寫得挺好的，都具有比較高的參考價值。但是我仔細梳理了我所看過的文章，發現大家基本上講的是restful的理論經驗，好像并沒有過多的提及restful實際程序設計上的一些經驗總結。而且關于這方面的經驗總結我曾經也想找找來做參考也并沒有找到，因此，我寫這篇文章，希望一些人能得到一些參考（因為是我個人實踐，可能有些不符合大流的地方，那就請多多包涵或者指出來了）。
另外這篇文章我不會去講一些底層restful支持怎么設計（restful框架怎么設計），要說這個的話，那么內容太長了，我主要講應用層面的東西，也就是具體業務邏輯的一些東西，當然會做一些基本的引申講解。
資源說到restful就不得不說資源這個東西了，restful的每一個接口所對應的應該是一個資源。那么，在restful里面，“資源”這個詞其實應該算是一個抽象概念了，這個“資源”所包含的資源就不僅僅是常規意義上的資源了。我覺得換一種方式叫法，把這種資源叫做對象，可能會更加方便理解。
當然，首先我們其實應該說一下什么是資源。資源包含的東西很多，從圖片到音頻、視頻等數據，以及文本等都是資源。也就是說，服務器上存在的數據就是資源。
但是，多帶帶說資源沒有太多意義，應該說資源的表現方式才有意義，或者說數據的表現方式才有意義，此處挺重要的，這個涉及到后續我說的restful風格設計方面的東西。通常來說，我們打開一個URL所能看到的就是一個完整的html界面，而其實，這個html界面就是資源，html所顯示出來的圖片、音頻、視頻等等都是資源。說到這里可能有些人在做開發過程中對于一些東西具有誤解，認為restful風格所獲取的資源是服務端返回json數據。關于這個，我們應該搞清楚幾個概念：
數據類型：就是服務端返回的數據類型，如html、圖片、視頻、Excel表格、world文檔等等；
傳輸方式：異步和同步；
串行和并行傳輸： 串行傳輸是等一個數據傳輸完成再傳輸另外一個數據，并行是同時執行。
這三個東西我就不展開細說了，說起來比較復雜，我就說一下串行和并行與異步和同步的一個大致講解就好了，很多人覺得異步是并行執行的，或者說把異步理解成并行執行的，這其實不一定，異步只能說執行的時候在某個流程執行的時候可以開始其他任務執行，減少阻塞。
請求方式常用的請求方式大致就是：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的標準，其實交互流程與傳統沒有太多差別，唯一的差別就是思想的轉換。分析以上，其實我們應該得出一些結論：
做restful設計的時候，程序設計思維應該要做一定的轉換，在不同的場景思考到底什么才應該是資源，應該把什么當做資源？
做restful應該把邏輯拆分得更清晰，沒個邏輯對象只做五件事情：看列表數據、看單個數據、增加數據、修改數據、刪除數據。
以上我雖然是就刪除來說的，其實批量修改等也貼合這種思想，也包括我之前回答的一個問題，就是批量閱讀消息這種操作也貼合于這種思想。
其他restful交互一般會遵循一些數據結構協議或者HTTP狀態值，比如不同的操作結果對應不同的HTTP狀態值，且出錯會返回指定的錯誤信息方便前端進行提示等。
當然restful接口的設計為了完全遵循自然語義也可以采用請求資源列表采用復數請求方式（語言中的單數詞和復數詞）等等。
不管怎么變化，我覺得最基本的還是不同的請求方式對應的不同操作問題，所有的操作對應的還是同一個接口。
以上就是我的一些應用場景的理解和總結，歡迎大家一起交流。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/25895.html
摘要：通常情況下，偽都是基于第一層次與第二層次設計的。為了解決這個版本不兼容問題，在設計的一種實用的做法是使用版本號。例如，建議第三位版本號通常表示兼容升級，只有不兼容時才需要變更服務版本。 原文地址：梁桂釗的博客 博客地址：blog.720ui.com 歡迎關注公眾號：「服務端思維」。一群同頻者，一起成長，一起精進，打破認知的局限性。 有一段時間沒怎么寫文章了，今天提筆寫一篇自己對 API 設...
摘要：通常情況下，偽都是基于第一層次與第二層次設計的。為了解決這個版本不兼容問題，在設計的一種實用的做法是使用版本號。例如，建議第三位版本號通常表示兼容升級，只有不兼容時才需要變更服務版本。 原文地址：梁桂釗的博客博客地址：http://blog.720ui.com 歡迎關注公眾號：「服務端思維」。一群同頻者，一起成長，一起精進，打破認知的局限性。 有一段時間沒怎么寫文章了，今天提筆寫一篇...
摘要：前端魔法堂異常不僅僅是在學習時我們會被告知異常和錯誤是不一樣的，異常是不會導致進程終止從而可以被修復，但錯誤將會導致進程終止因此不能被修復。 推薦 1. RESTful API 設計最佳實踐 https://blog.philipphauer.de/... 項目資源的URL應該如何設計？用名詞復數還是用名詞單數？一個資源需要多少個URL？用哪種HTTP方法來創建一個新的資源？可選參數應...
閱讀 1975·2021-11-24 09:38
閱讀 3338·2021-11-22 12:07
閱讀 1902·2021-09-22 16:03
閱讀 1955·2021-09-02 15:41
閱讀 2617·2021-07-24 23:28
閱讀 2210·2019-08-29 13:17
閱讀 1546·2019-08-29 12:25
閱讀 2666·2019-08-29 11:10
