什么是REST？

REST是表述性狀態(tài)傳輸( REpresentational  State Transfer)的縮寫 ，是分布式超媒體系統(tǒng)的一種架構(gòu)風(fēng)格 。 Roy Fielding 于 2000 年在他的著名論文中首次提出了這一點(diǎn) 。從那時起，它已成為構(gòu)建基于 Web 的 API（應(yīng)用程序編程接口）的最廣泛使用的方法之一。

REST 不是一種協(xié)議或標(biāo)準(zhǔn)，而是一種架構(gòu)風(fēng)格。在開發(fā)階段，API 開發(fā)人員可以通過多種方式實(shí)現(xiàn) REST。

與其他架構(gòu)風(fēng)格一樣，REST 也有其指導(dǎo)原則和約束。如果服務(wù)接口必須稱為 RESTful ，則必須滿足這些原則。

REST 的六大指導(dǎo)原則

REST 基于一些促進(jìn)設(shè)計簡單性、可擴(kuò)展性和無狀態(tài)性的約束和原則。RESTful 架構(gòu)的六個指導(dǎo)原則或約束是：

1.統(tǒng)一接口

通過將 通用性原則應(yīng)用于 組件接口，我們可以簡化整個系統(tǒng)架構(gòu)并提高交互的可見性。多個架構(gòu)約束有助于獲得統(tǒng)一的接口并指導(dǎo)組件的行為。

以下四個約束可以實(shí)現(xiàn)統(tǒng)一的REST接口：

• 資源標(biāo)識 ——接口必須唯一標(biāo)識客戶端和服務(wù)器之間交互所涉及的每個資源。
• 通過表示操作資源 ——資源在服務(wù)器響應(yīng)中應(yīng)該有統(tǒng)一的表示。 API 使用者應(yīng)該使用這些表示來修改服務(wù)器中的資源狀態(tài)。
• 自描述消息 ——每個資源表示應(yīng)該攜帶足夠的信息來描述如何處理消息。它還應(yīng)該提供客戶端可以對資源執(zhí)行的其他操作的信息。
• 超媒體作為應(yīng)用程序狀態(tài)的引擎 ——客戶端應(yīng)該只有應(yīng)用程序的初始 URI?？蛻舳藨?yīng)用程序應(yīng)使用超鏈接動態(tài)驅(qū)動所有其他資源和交互。

簡而言之，REST 為客戶端和服務(wù)器之間的交互定義了一致且統(tǒng)一的接口。例如，基于 HTTP 的 REST API 使用標(biāo)準(zhǔn) HTTP 方法（GET、POST、PUT、DELETE 等）和 URI（統(tǒng)一資源標(biāo)識符）來標(biāo)識資源。

2.客戶端服務(wù)器

客戶端-服務(wù)器設(shè)計模式強(qiáng)制 關(guān)注點(diǎn)分離，這有助于客戶端和服務(wù)器組件獨(dú)立發(fā)展。

通過將用戶界面問題（客戶端）與數(shù)據(jù)存儲問題（服務(wù)器）分離，我們提高了用戶界面跨多個平臺的可移植性，并通過簡化服務(wù)器組件來提高可擴(kuò)展性。

當(dāng)客戶端和服務(wù)器不斷發(fā)展時，我們必須確保客戶端和服務(wù)器之間的接口/契約不會中斷。

3.無國籍

無狀態(tài)性要求從客戶端到服務(wù)器的每個請求都必須包含理解和完成請求所需的所有信息。

服務(wù)器無法利用服務(wù)器上任何先前存儲的上下文信息。

因此，客戶端應(yīng)用程序必須完全保留會話狀態(tài)。

4.可緩存

可緩存約束要求響應(yīng)應(yīng)隱式或顯式地將自身標(biāo)記為可緩存或不可緩存。

如果響應(yīng)是可緩存的，則客戶端應(yīng)用程序有權(quán)稍后在指定時間段內(nèi)針對等效請求重用響應(yīng)數(shù)據(jù)。

5.分層系統(tǒng)

分層系統(tǒng)風(fēng)格允許通過約束組件行為來將體系結(jié)構(gòu)由層次結(jié)構(gòu)層組成。在分層系統(tǒng)中，每個組件都無法看到與其交互的直接層之外的內(nèi)容。

分層系統(tǒng)的外行示例是MVC 模式。 MVC 模式允許清晰地分離關(guān)注點(diǎn)，從而更輕松地開發(fā)、維護(hù)和擴(kuò)展應(yīng)用程序。

6.按需編碼（可選）

REST 還允許通過下載和執(zhí)行小程序或腳本形式的代碼來擴(kuò)展客戶端功能。

下載的代碼通過減少需要預(yù)先實(shí)現(xiàn)的功能數(shù)量來簡化客戶端。服務(wù)器可以將部分功能以代碼的形式傳遞給客戶端，客戶端只需要執(zhí)行代碼即可。

什么是資源？

 REST 中信息的關(guān)鍵抽象是資源?？梢悦娜魏涡畔⒍伎梢允琴Y源。例如，REST資源可以是文檔或圖像、臨時服務(wù)、其他資源的集合或非虛擬對象（例如，人）。

任何特定時間的資源狀態(tài)稱為 資源表示。資源表示包括：

• 數(shù)據(jù) ?
•  描述數(shù)據(jù)的元數(shù)據(jù) 
• 以及  可以幫助客戶過渡到下一個所需狀態(tài)的超媒體鏈接。

1.資源標(biāo)識符

REST 使用資源標(biāo)識符來標(biāo)識客戶端和服務(wù)器組件之間交互所涉及的每個資源。

2.超媒體

表示的數(shù)據(jù)格式稱為 媒體類型。媒體類型標(biāo)識定義如何處理表示的規(guī)范。

RESTful API 看起來像超文本。每個可尋址信息單元都攜帶一個地址，或者顯式地（例如，鏈接和id屬性）或者隱式地（例如，從媒體類型定義和表示結(jié)構(gòu)導(dǎo)出）。

3.自描述

此外， 資源表示應(yīng)該是自描述的：客戶端不需要知道資源是員工還是設(shè)備。它應(yīng)該根據(jù)與資源關(guān)聯(lián)的媒體類型進(jìn)行操作。

因此，在實(shí)踐中，我們將創(chuàng)建許多自定義媒體類型 - 通常一種媒體類型與一種資源相關(guān)聯(lián)。

每種媒體類型都定義了默認(rèn)的處理模型。例如，HTML 定義了超文本的呈現(xiàn)過程以及每個元素周圍的瀏覽器行為。

資源方法

與 REST 相關(guān)的另一個重要的事情是 資源方法。這些資源方法用于執(zhí)行任何資源的兩種狀態(tài)之間所需的轉(zhuǎn)換。

很多人錯誤地將資源方法與 HTTP 方法 （即 GET/PUT/POST/DELETE）聯(lián)系起來。羅伊·菲爾丁 (Roy Fielding) 從未提及過在哪種情況下使用哪種方法的任何建議。他只是強(qiáng)調(diào)它應(yīng)該是一個 統(tǒng)一的界面。

例如，如果我們決定應(yīng)用程序 API 將使用 HTTP POST 來更新資源（而不是大多數(shù)人推薦的 HTTP PUT），那就沒問題。盡管如此，應(yīng)用程序界面仍將是 RESTful 的。

理想情況下，轉(zhuǎn)換資源狀態(tài)所需的一切都應(yīng)成為資源表示的一部分 - 包括所有支持的方法以及它們將以什么形式離開表示。

REST 和 HTTP 不一樣

許多人更喜歡將 HTTP 與 REST 進(jìn)行比較。  REST 和 HTTP 不一樣。

盡管 REST 也旨在使 Web（互聯(lián)網(wǎng)）更加精簡和標(biāo)準(zhǔn)化，但 Roy Fielding 主張更嚴(yán)格地使用 REST 原則。這就是人們嘗試開始將 REST 與 Web 進(jìn)行比較的地方。

Roy Fielding 在他的論文中沒有提到任何實(shí)現(xiàn)方向——包括任何協(xié)議偏好甚至 HTTP。到目前為止，我們一直遵守 REST 的六項指導(dǎo)原則，我們可以將其稱為我們的界面 – RESTful。

總結(jié)

簡而言之，在 REST 架構(gòu)風(fēng)格中，數(shù)據(jù)和功能被視為資源，并使用 統(tǒng)一資源標(biāo)識符 (URI) 進(jìn)行訪問。

通過使用一組簡單、定義明確的操作來對資源進(jìn)行操作。此外，資源必須與其表示形式分離，以便客戶端可以訪問各種格式的內(nèi)容，例如 HTML、XML、純文本、PDF、JPEG、JSON 等。

客戶端和服務(wù)器通過使用標(biāo)準(zhǔn)化的接口和協(xié)議來交換資源的表示。通常 HTTP 是最常用的協(xié)議，但 REST 并不強(qiáng)制要求它。

有關(guān)資源的元數(shù)據(jù)可用并用于控制緩存、檢測傳輸錯誤、協(xié)商適當(dāng)?shù)谋硎靖袷揭约皥?zhí)行身份驗(yàn)證或訪問控制。

最重要的是，與服務(wù)器的每次交互都必須是無狀態(tài)的。

所有這些原則都有助于 RESTful 應(yīng)用程序變得簡單、輕量級和快速。