REST詳述及RESTful規範
RESTful是一種軟體的架構風格、設計風格,為客戶端和服務端的互動提供了一組設計原則和約束條件.
如果一個架構符合REST的約束條件和原則,那麼我們將稱它為RESTful架構.
文章目錄
Web服務互動
我們在瀏覽器中能看到的每個網站,都是一個web服務。那麼我們在提供每個web服務的時候,都需要前後端互動,前後端互動就一定有一些實現方案,我們通常叫web服務互動方案。
目前主流的三種web服務互動方案:
1. REST
(Respresentational State Transfer)表述性狀態轉移.
2. SOAP
(Simple Object Access Protocol) 簡單的物件訪問協議.
3. XML-RPC
(XML Remote Procedure Call)基於XML的遠端過程呼叫.
XML-RPC是通過XML將呼叫函式封裝,並使用HTTP協議作為傳送機制。
後來在新的功能不斷被引入下,這個標準慢慢演變成為今日的SOAP協定。
SOAP服務則是以本身所定義的操作集,來訪問網路上的資源。
SOAP也是基於XML的,但是它不只限於HTTP協議的傳輸,包括TCP協議,UDP協議都可以傳輸。
REST是Roy Thomas Fielding博士於2000年在他的博士論文裡提出來的。
REST相比SOAP更加簡潔,效能和開發效率也有突出的優勢。
我們今天主要說一下這個REST,現在越來越多的web服務開始採用REST風格設計和實現。
例如,amazon.com提供接近REST風格的Web服務進行圖書查詢;雅虎提供的Web服務也是REST風格的。
理解REST
如果我們想要理解restful,就得先理解Representational State Transfer這個片語的意思——表徵性狀態轉移.
所謂的表徵性狀態轉移,其實指的就是資源,通常我們稱之為資源狀態轉移.
什麼是資源?
任何事物,只要有被引用的必要,那麼它就是一個資源.
我們在瀏覽器中看到的文字、圖片、視訊等等都是資源,這些都是實實在在存在的實體.
資源可以是一個實體,也可以是抽象概念,比如:
- 錦覓的個人資訊
- 火神的琉璃淨火
- 錦覓跟火神的關係
在網路中,我們要引用的資源,一定要有一個標識,在Web中的唯一標識就是URI.
URI我們不常聽說,我們經常用的是URL,兩者的區別如下.
什麼是URI、URL?
URI 統一資源標誌符
URL 統一資源定位符
沒錯,URI是給我們的資源進行標識的,URL是描述我們的資源地址的.
比如,我們每個人都有名字和身份證,名字可能會重複,但身份證是唯一的.
那麼身份證號就可以是我們的URI,標識我們每個人,也可以說是標識我們每個人的資源.
我們可以通過身份證號找到嫦娥,也可以通過下面這種方式找到她…
嫦娥的住址:某某世界->銀河系->獵戶臂->太陽系->月亮…
這就是我們的URL.
我們通過這兩種方式都可以找到我們的資源.
其實我們的URL可以說是URI的子集,通過定位的方式實現的URI.
這便是我們的資源定位,有了資源的地址後,我們是要去訪問資源的.
那麼我們如何訪問資源呢?如下.
統一資源介面
我們通過URL去訪問到資源,我們對資源會有很多不同的操作——增刪改查.
以前我們可能會為了"增加"的功能,而設計一個新的URL,然後這個URL就只負責對資料的增加,還會為了更新和刪除再分別設計一個URL.
現在我們不用了,我們只需一個URL,然後根據HTTP請求方式的不同,對資源進行不同的操作,這個就是統一資源介面.
我們一定要遵循HTTP請求方式的語義,也就是說POST請求就在新增資料等…
資源的表述
資源的表述其實就是資源的展現形式,我們客戶端和服務端傳輸的都是資源的表述,而不是資源本身.
例如文字資源可以採用html、xml、json等格式,圖片可以使用PNG或JPG展現出來.
那麼客戶端如何知道服務端提供哪種表述形式呢?
可以通過HTTP內容協商,客戶端可以通過Accept頭請求一種特定格式的表述,服務端則通過Content-Type告訴客戶端資源的表述形式。
這些資源的表述呈現在頁面上,就是我們說的資源狀態.
狀態轉移
我們在看頁面的時候,從當前資源的表述(也可以說狀態或者表現層)會跳轉到其他的資源狀態。
服務端通過超媒體協議告訴客戶端當前狀態有哪些後續狀態可以進入。
這些類似"下一頁"之類的連結起的就是這種推進狀態的作用——指引你如何從當前狀態進入下一個可能的狀態。
小結
總結下來,REST風格的特點如下:
- 在Web中,只要有被引用的必要,都叫資源.
- 每個URI代表一個資源,獨一無二的.
- 客戶端通過HTTP的方法,對伺服器端資源進行操作.
- 客戶端和伺服器之間,傳遞這種資源的某種表現層.
- 通過超連結的指引,實現"表現層狀態轉移".
RESTful規範
- 面向資源程式設計
- 每個URL代表一種資源,URL中儘量不要用動詞,要用名詞.
- 根據請求方式的不同,對資源進行不同的操作
- GET/POST/PUT/DELETE/PATCH
- 在URL中體現版本
- ·
- 在URL中體現是否是API
- ·
- 在URL中的過濾條件
- 比如:https:/ /www.bootcss.com/v1/mycss?page=3
- 儘量使用HTTPS協議
- 比如:https:/ /www.bootcss.com/v1/mycss
- 響應時設定狀態碼
- 100 資訊,伺服器收到請求,需要請求者繼續執行操作.
- 200 成功,操作被成功接收並處理.
- 300 重定向,需要進一步的操作以完成請求.
- 400 客戶端錯誤,請求包含語法錯誤或無法完成請求.
- 500 伺服器錯誤,伺服器在處理請求的過程中發生了錯誤.
- 也可以是自定義的狀態碼.
- 返回值
- get 返回檢視的所有或單條資料
- post 返回更新的某條資料
- put/patch 返回更新的某條資料
- delete 返回值為空
- Hypermedia API
- 如果遇到需要跳轉的情況,請攜帶跳轉介面的URL.
is ok.