1.背景介紹
要解釋什麼是REST，你應該先了解什麼是API（Application Programming Interface,應用程序編程接口）， 形象一點說就是像一個公司比如騰訊，阿里巴巴之類，他們可以提供一個API，然後我們或者一些其他的小公司可以編一個軟件去跟這個接口（API）進行相連或交互。
舉個例子，比如你可以用手機的其他軟件分享內容到微信朋友圈或者新浪微博，這些軟件就是與微信和微博的api進行了交互。知道了API，那麼就容易理解REST了。它是一種架構風格，騰訊公司或其他公司建立API時要遵守的一種規則/風格，當然也有其他規則可以用。
要具體知道什麼是REST，我們又必須提到Web，因爲REST是以Web爲平臺的。Web是分佈式信息系統爲超文本文件和其他對象（資源）提供訪問入口。
資源是Web架構的關鍵點,需要3個操作:
識別(identify)，表示(represent)，交互(interact with)
通過這三個操作，又引出三個概念:
1.uri（統一資源標識符包括url和urn）識別資源；
2.representation （例如html，圖片，視頻等等）表示資源；
3.通過協議（包括http，ftp等等）與資源進行交互。
所以REST就是選擇通過使用http協議和uri，利用client/server model對資源進行CRUD(Create/Read/Update/Delete)增刪改查操作。
2.知識剖析
REST不是"rest"這個單詞，而是Resource Representational State Transfer的縮寫：通俗來講就是：資源在網絡中以某種表現形式進行狀態轉移。分開來講：
1.Resource：資源，即數據（網絡的核心）。
2.Representational：某種表現形式，比如用JSON，XML，JPEG等；
3.State Transfer：狀態變化。通過HTTP動詞實現。
-
REST描述的是在網絡中client和server的一種交互形式；REST本身不實用，實用的是如何設計 RESTful API（REST風格的網絡接口；
-
Server提供的RESTful API中，URL中只使用名詞來指定資源，原則上不使用動詞。“資源”是REST架構或者說整個網絡處理的核心。
-
用HTTP協議裏的動詞來實現資源的添加，修改。
-
Server和Client之間傳遞某資源的一個表現形式，比如用JSON，XML傳輸文本，或者用JPG，WebP傳輸圖片等。
-
用 HTTP Status Code傳遞Server的狀態信息。比如最常用的 200 表示成功，500 表示Server內部錯誤等。
Web端不再用之前典型的PHP或JSP架構，而是改爲前段渲染和附帶處理簡單的商務邏輯。Web端和Server只使用上述定義的API來傳遞數據和改變數據狀態。格式一般是JSON。
對於資源的具體操作類型，由HTTP動詞表示。常用的HTTP動詞有下面五個（括號裏是對應的SQL命令）：
1.GET（SELECT）： 從服務器獲取資源(一項或多項)
2.POST（CREATE）： 在服務器新建一個資源
3.PUT（UPDATE）： 在服務器更新資源（客戶端提供改變後的完整資源）
4.PATCH（UPDATE）： 在服務器更新資源（客戶端提供改變的屬性）
5.DELETE（DELETE）：從服務器刪除資源。
比如：
GET /zoos：列出所有動物園
POST /zoos：新建一個動物園
GET /zoos/ID：獲取某個指定動物園的信息
PUT /zoos/ID：更新某個指定動物園的信息（提供該動物園的全部信息
PATCH /zoos/ID：更新某個指定動物園的信息（提供該動物園的部分信息）
DELETE /zoos/ID：刪除某個動物園
GET /zoos/ID/animals：列出某個指定動物園的所有動物
DELETE /zoos/ID/animals/ID：刪除某個指定動物園的指定動物
3.常見問題
Server的API如何設計才滿足RESTful要求?
-
URL root:
https://example.org/api/v1/*
https://api.example.com/v1/ -
API versioning:
可以放在URL裏面，也可以用HTTP的header：/api/v1/ -
URI使用名詞而不是動詞，且推薦用複數。
-
保證HEAD和GET方法是安全的，不會對資源狀態有所改變（污染）。
-
資源的地址推薦用嵌套結構：
GET /friends/10375923/profile
爲什麼要用RESTful結構呢？
大家都知道"古代"網頁是前端後端融在一起的。在之前的桌面時代問題不大，但是近年來移動互聯網的發展，各種類型的Client層出不窮，RESTful可以通過一套統一的接口爲Web,iOS和Android提供服務。另外對於廣大平臺來說，比如Facebook，微博開放平臺，微信公共平臺等，它們不需要有顯式的前端，只需要一套提供服務的接口。
REST的優點和限制
1.客戶-服務器（Client-Server）客戶端服務器分離
優點:
提高用戶界面的便攜性（操作簡單）
通過簡化服務器提高可伸縮性（高性能，低成本）
允許組件分別優化（可以讓服務端和客戶端分別進行改進和優化）
2.無狀態（Stateless）
從客戶端的每個請求要包含服務器所需要的所有信息
優點:
提高可見性（可以單獨考慮每個請求）
提高了可靠性（更容易從局部故障中修復）
提高可擴展性（降低了服務器資源使用）
3.緩存（Cachable）
服務器返回信息必須被標記是否可以緩存，如果緩存，客戶端可能會重用之前的信息發送請求。
優點:減少交互次數,減少交互的平均延遲。
4.分層系統（Layered System）
系統組件不需要知道與他交流組件之外的事情。封裝服務，引入中間層。
優點:限制了系統的複雜性,提高可擴展性。
5.統一接口（Uniform Interface）
優點:提高交互的可見性,鼓勵單獨改善組件。
6.支持按需代碼（Code-On-Demand）
優點:提高可擴展性
4.擴展思考
舉個例子：
例如我訂閱了一個人的博客，想要獲取他發表的所有文章（這裏『他發表的所有文章』就是一個資源Resource）。於是我就向他的服務發出請求，說『我要獲取你發表的所有文章，最好是atom格式的』，這時候服務器向你返回了atom格式的文章列表第一頁（這裏『atom格式的文章列表』就是表徵Representation）。
你看到了第一頁的頁尾，想要看第二頁，這時候有趣的事情就來了。如果服務器記錄了應用的狀態（stateful），那麼你只要向服務詢問『我要看下一頁』，那麼服務器自然就會返回第二頁。類似的，如果你當前在第二頁，想服務器請求『我要看下一頁』，那就會得到第三頁。但是REST的服務器恰恰是無狀態的（stateless），服務器並沒有保持你當前處於第幾頁，也就無法響應『下一頁』這種具有狀態性質的請求。因此客戶端需要去維護當前應用的狀態（application state），也就是『如何獲取下一頁資源』。
當然，『下一頁資源』的業務邏輯必然是由服務端來提供。服務器在文章列表的atom表徵中加入一個URI超鏈接（hyper link），指向下一頁文章列表對應的資源。客戶端就可以使用統一接口（Uniform Interface）的方式，從這個URI中獲取到他想要的下一頁文章列表資源。上面的『能夠進入下一頁』就是應用的狀態（State）。服務器把『能夠進入下一頁』這個狀態以atom表徵形式傳輸（Transfer）給客戶端就是表徵狀態傳輸（REpresentational State Transfer）這個概念。
5.參考文獻
JSON的編碼規範：http://jsonapi.org/format/
怎樣用通俗的語言解釋REST，以及RESTful？：https://www.zhihu.com/question/28557115
PPT:
https://ptteng.github.io/PPT/PPT/JS-11-%E4%BB%80%E4%B9%88%E6%98%AFREST.html#/
視頻:
https://v.qq.com/x/page/j05432i5xuc.html
作者：我叫於搞吧
鏈接：https://www.jianshu.com/p/350122cf63f2
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。