RESTful 是目前最流行的 API 設計規范，用于 Web 資料介面的設計，
什么是RESTful
RESTful是一種軟體設計風格, 主要用于客戶端與服務端互動的軟體. 一般來說RESTful API基于HTTP協議, 通過某個唯一識別符號(URI)請求對應的服務器資源(Resource).通常我們把RESTful API編程也叫做”介面編程”.
RESTful API基于HTTP協議, 實作了通用的前后端互動, 前端通過某個URI告訴后端執行對應的操作, 并回傳需要的資源, 可以很好的實作前后端分離.
什么場景下使用RESTful API
在當今的互聯網應用的前端展示媒介很豐富，有手機、有平板電腦還有PC以及其他的展示媒介，那么這些前端接收到的用戶請求統一由一個后臺來處理并回傳給不同的前端肯定是最科學和最經濟的方式，RESTful API就是一套協議來規范多種形式的前端和同一個后臺的互動方式，
RESTful API由后臺也就是SERVER來提供前端來呼叫，前端呼叫API向后臺發起HTTP請求，后臺回應請求將處理結果反饋給前端，也就是說RESTful 是典型的基于HTTP的協議，那么RESTful API有哪些設計原則和規范呢？
1，資源，首先是弄清楚資源的概念，資源就是網路上的一個物體，一段文本，一張圖片或者一首歌曲，資源總是要通過一種載體來反應它的內容，文本可以用TXT，也可以用HTML或者XML、圖片可以用JPG格式或者PNG格式，JSON是現在最常用的資源表現形式，
2，統一介面，RESTful風格的資料元操CRUD（create,read,update,delete）分別對應HTTP方法：GET用來獲取資源，POST用來新建資源（也可以用于更新資源），PUT用來更新資源，DELETE用來洗掉資源，這樣就統一了資料操作的介面，
3，URI，可以用一個URI（統一資源定位符）指向資源，即每個URI都對應一個特定的資源，要獲取這個資源訪問它的URI就可以，因此URI就成了每一個資源的地址或識別符，一般的，每個資源至少有一個URI與之對應，最典型的URI就是URL，
4，無狀態，所謂無狀態即所有的資源都可以URI定位，而且這個定位與其他資源無關，也不會因為其他資源的變化而變化，有狀態和無狀態的區別，舉個例子說明一下：
例如要查詢員工工資的步驟為第一步：登錄系統，第二步：進入查詢工資的頁面，第三步：搜索該員工，第四步：點擊姓名查看工資，這樣的操作流程就是有狀態的，查詢工資的每一個步驟都依賴于前一個步驟，只要前置操作不成功，后續操作就無法執行，
如果輸入一個URL就可以得到指定員工的工資，則這種情況就是無狀態的，因為獲取工資不依賴于其他資源或狀態，且這種情況下，員工工資是一個資源，由一個URL與之對應可以通過HTTP中的GET方法得到資源，這就是典型的RESTful風格，
RESTful 的設計細節
一 URL設計
動詞+賓語
RESTful的核心思想就是，客戶端發出的資料+操作指令都是“動詞+賓語”的結構，比如GET /articles這個命令，GET是動詞，/articles是賓語，動詞通常就有5種HTTP請求方法，對應CRUD操作，根據 HTTP 規范，動詞一律大寫，
動詞的覆寫
有些客戶端只能使用GET和POST這兩種方法，服務器必須接受POST模擬其他三個方法（PUT、PATCH、DELETE），這時，客戶端發出的 HTTP 請求，要加上X-HTTP-Method-Override屬性，告訴服務器應該使用哪一個動詞，覆寫POST方法，
上面代碼中，X-HTTP-Method-Override指定本次請求的方法是PUT，而不是POST，
賓語必須是名詞
賓語就是 API 的 URL，是 HTTP 動詞作用的物件，它應該是名詞，不能是動詞，比如，/articles這個 URL 就是正確的，而下面的 URL 不是名詞，所以都是錯誤的，
復數 URL
既然 URL 是名詞，那么應該使用復數，還是單數？這沒有統一的規定，但是常見的操作是讀取一個集合，比如GET /articles（讀取所有文章），這里明顯應該是復數，
為了統一起見，建議都使用復數 URL，比如GET /articles/2要好于GET /article/2，
避免多級 URL
常見的情況是，資源需要多級分類，因此很容易寫出多級的 URL，比如獲取某個作者的某一類文章，
這種 URL 不利于擴展，語意也不明確，往往要想一會，才能明白含義，
更好的做法是，除了第一級，其他級別都用查詢字串表達，
下面是另一個例子，查詢已發布的文章，你可能會設計成下面的 URL，
查詢字串的寫法明顯更好
二、狀態碼
狀態碼必須精確
客戶端的每一次請求，服務器都必須給出回應，回應包括 HTTP 狀態碼和資料兩部分，
HTTP 狀態碼就是一個三位數，分成五個類別，
這五大類總共包含100多種狀態碼，覆寫了絕大部分可能遇到的情況，每一種狀態碼都有標準的（或者約定的）解釋，客戶端只需查看狀態碼，就可以判斷出發生了什么情況，所以服務器應該回傳盡可能精確的狀態碼，
API 不需要1xx狀態碼，下面介紹其他四類狀態碼的精確含義，
2XX狀態碼
200狀態碼表示操作成功，但是不同的方法可以回傳更精確的狀態碼，
上面代碼中，POST回傳201狀態碼，表示生成了新的資源；DELETE回傳204狀態碼，表示資源已經不存在，
此外，202 Accepted狀態碼表示服務器已經收到請求，但還未進行處理，會在未來再處理，通常用于異步操作，下面是一個例子，
3xx 狀態碼
API 用不到301狀態碼（永久重定向）和302狀態碼（暫時重定向，307也是這個含義），因為它們可以由應用級別回傳，瀏覽器會直接跳轉，API 級別可以不考慮這兩種情況，
API 用到的3xx狀態碼，主要是303 See Other，表示參考另一個 URL，它與302和307的含義一樣，也是"暫時重定向"，區別在于302和307用于GET請求，而303用于POST、PUT和DELETE請求，收到303以后，瀏覽器不會自動跳轉，而會讓用戶自己決定下一步怎么辦，
下面是一個例子，
4xx 狀態碼
4xx狀態碼表示客戶端錯誤，主要有下面幾種，
-
400 Bad Request：服務器不理解客戶端的請求，未做任何處理，
-
401 Unauthorized：用戶未提供身份驗證憑據，或者沒有通過身份驗證，
-
403 Forbidden：用戶通過了身份驗證，但是不具有訪問資源所需的權限，
-
404 Not Found：所請求的資源不存在，或不可用，
-
405 Method Not Allowed：用戶已經通過身份驗證，但是所用的 HTTP 方法不在他的權限之內，
-
410 Gone：所請求的資源已從這個地址轉移，不再可用，
-
415 Unsupported Media Type：客戶端要求的回傳格式不支持，比如，API 只能回傳 JSON 格式，但是客戶端要求回傳 XML 格式，
-
422 Unprocessable Entity ：客戶端上傳的附件無法處理，導致請求失敗，
-
429 Too Many Requests：客戶端的請求次數超過限額，
5xx 狀態碼
5xx狀態碼表示服務端錯誤，一般來說，API 不會向用戶透露服務器的詳細資訊，所以只要兩個狀態碼就夠了，
-
500 Internal Server Error：客戶端請求有效，服務器處理時發生了意外，
-
503 Service Unavailable：服務器無法處理請求，一般用于網站維護狀態，
三、服務器回應
不要回傳純本文
API 回傳的資料格式，不應該是純文本，而應該是一個 JSON 物件，因為這樣才能回傳標準的結構化資料，所以，服務器回應的 HTTP 頭的Content-Type屬性要設為application/json，
客戶端請求時，也要明確告訴服務器，可以接受 JSON 格式，即請求的 HTTP 頭的ACCEPT屬性也要設成application/json，下面是一個例子，
發生錯誤時，不要回傳 200 狀態碼
有一種不恰當的做法是，即使發生錯誤，也回傳200狀態碼，把錯誤資訊放在資料體里面，就像下面這樣，
上面代碼中，決議資料體以后，才能得知操作失敗，
這張做法實際上取消了狀態碼，這是完全不可取的，正確的做法是，狀態碼反映發生的錯誤，具體的錯誤資訊放在資料體里面回傳，下面是一個例子，
提供鏈接
API 的使用者未必知道，URL 是怎么設計的，一個解決方法就是，在回應中，給出相關鏈接，便于下一步操作，這樣的話，用戶只要記住一個 URL，就可以發現其他的 URL，這種方法叫做 HATEOAS，
舉例來說，GitHub 的 API 都在 api.github.com 這個域名，訪問它，就可以得到其他 URL，
上面的回應中，挑一個 URL 訪問，又可以得到別的 URL，對于用戶來說，不需要記住 URL 設計，只要從 api.github.com 一步步查找就可以了，
HATEOAS 的格式沒有統一規定，上面例子中，GitHub 將它們與其他屬性放在一起，更好的做法應該是，將相關鏈接與其他屬性分開，
以上是文章全部內容，有需要學習交流的友人請加入交流群的咱們一起，有問題一起交流，一起進步！前提是你是學技術的，感謝閱讀！
點此加入該群
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/103774.html
標籤：PHP
上一篇：PHP開發各種規范，面試秘籍！