什麼是 rest api

Home >> Blog >> 什麼是 rest api

停下手邊的SEO search engine optimization 搜尋引擎優化方案，讓我們進入rest api 的討論內容。

REST 是 REpresentational State Transfer 的首字母縮寫，是分佈式超媒體系統的一種架構風格。羅伊菲爾丁於 2000 年在他著名的論文中首次提出它。

與其他架構風格一樣，REST 有其指導原則和約束。如果需要將服務介面稱為RESTful，則必須滿足這些原則。

符合 REST 架構風格的 Web API（或 Web 服務）是 REST API。

1. REST 的指導原則

RESTful 架構的六個指導原則或約束是：

1.1。統一介面

通過將通用性原則應用於組件介面，我們可以簡化整個系統架構並提高交互的可見性。

多個架構約束有助於獲得統一的介面並指導組件的行為。

以下四個約束可以實現統一的 REST 介面：

資源標識 ——介面必須唯一標識客戶端和伺服器之間交互中涉及的每個資源。
通過表示操作資源 ——資源在伺服器響應中應該有統一的表示。API 使用者應該使用這些表示來修改伺服器中的資源狀態。
自描述消息 ——每個資源表示應該攜帶足夠的資訊來描述如何處理消息。它還應該提供客戶端可以對資源執行的附加操作的資訊。
超媒體作為應用程式狀態的引擎 ——客戶端應該只有應用程式的初始 URI。客戶端應用程式應該使用超連結動態驅動所有其他資源和交互。

1.2. 客戶端伺服器

客戶端-伺服器設計模式強制關注點分離，這有助於客戶端和伺服器組件獨立發展。

通過將用戶界面關注點（客戶端）與數據存儲關注點（伺服器）分離，我們提高了用戶界面跨多個平台的可移植性，並通過簡化伺服器組件來提高可擴展性。

在客戶端和伺服器發展的同時，我們必須確保客戶端和伺服器之間的介面/契約不會中斷。

1.3. 無狀態

無狀態要求從客戶端到伺服器的每個請求都必須包含理解和完成請求所需的所有資訊。

伺服器無法利用伺服器上任何先前存儲的上下文資訊。

因此，客戶端應用程式必須完全保持會話狀態。

1.4. 可緩存

可緩存約束要求響應應隱式或顯式地將自身標記為可緩存或不可緩存。

如果響應是可緩存的，則客戶端應用程式有權在稍後為等效請求和指定時間段重用響應數據。

1.5。分層系統

分層系統樣式允許通過約束組件行為來由分層層組成架構。

例如，在分層系統中，每個組件都無法看到它們正在與之交互的直接層之外。

1.6. 按需編寫程式碼（可選）

REST 還允許通過以小程式或腳本的形式下載和執行代碼來擴展客戶端功能。

下載的代碼通過減少需要預先實現的功能數量來簡化客戶端。伺服器可以將部分功能以代碼的形式交付給客戶端，客戶端只需要執行代碼即可。

2. 什麼是資源？

REST 中資訊的關鍵抽像是資源。我們可以命名的任何資訊都可以是資源。例如，REST 資源可以是文檔或圖像、時間服務、其他資源的集合或非虛擬對象（例如，人）。

資源在任何特定時間的狀態稱為資源表示。

資源表示包括：

數據_
描述數據的元數據
以及可以幫助客戶過渡到下一個所需狀態的超媒體連結。

一個 REST API 由一組相互關聯的資源組成。這組資源稱為 REST API 的資源模型。

2.1。資源標識符

REST 使用資源標識符來識別客戶端和伺服器組件之間交互中涉及的每個資源。

2.2. 超媒體

表示的數據格式稱為媒體類型。媒體類型標識了一個規範，該規範定義瞭如何處理表示。

RESTful API 看起來像超文本。每個可尋址的資訊單元都攜帶一個地址，或者顯式（例如，連結和 id 屬性）或隱式（例如，從媒體類型定義和表示結構派生）。

超文本（或超媒體）意味著資訊和控制的同時呈現，使得資訊成為用戶（或自動機）獲得選擇和選擇動作的可供性。

請記住，超文本在瀏覽器上不需要是 HTML（或 XML 或 JSON）。當機器了解數據格式和關係類型時，它們可以跟踪連結。

— 羅伊·菲爾丁

2.3. 自我描述

此外，資源表示應該是自描述的：客戶端不需要知道資源是員工還是設備。它應該根據與資源相關聯的媒體類型進行操作。

所以在實踐中，我們將創建許多自定義媒體類型 ——通常是一種媒體類型與一種資源相關聯。

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

媒體類型與資源方法 GET/PUT/POST/DELETE/... 沒有任何關係，除了一些媒體類型元素將定義一個流程模型，類似於“具有href屬性的錨元素創建一個超文本連結，當選擇該連結時，在對應於CDATA-encodedhref屬性的 URI 上調用檢索請求 (GET)。”

3. 資源方法

與 REST 相關的另一個重要的事情是資源方法。這些資源方法用於在任何資源的兩種狀態之間執行所需的轉換。

很多人錯誤地將資源方法與 HTTP 方法（即 GET/PUT/POST/DELETE）相關聯。Roy Fielding 從未提及任何關於在何種條件下使用哪種方法的建議。他所強調的只是它應該是一個統一的界面。

例如，如果我們決定應用程式 API 將使用 HTTP POST 來更新資源——而不是大多數人推薦的 HTTP PUT——那沒關係。儘管如此，應用程式界面仍將是 RESTful。

理想情況下，轉換資源狀態所需的一切都應該是資源表示的一部分——包括所有支持的方法以及它們將以何種形式離開表示。

我們應該輸入一個 REST API，除了初始 URI（書籤）和一組適合目標受眾（即，任何可能使用 API 的客戶端都可以理解）的標準化媒體類型之外，沒有任何先驗知識。

從那時起，所有應用程式狀態轉換必須由客戶端選擇的伺服器提供的選項驅動，該選項存在於接收到的表示中，或者由用戶對這些表示的操作暗示。

轉換可以由客戶端對媒體類型和資源通信機制的了解來確定（或限制），這兩者都可以在運行中得到改進（例如，按需編寫程式碼）。[這裡的失敗意味著帶外資訊正在推動交互而不是超文本。]

4. REST 和 HTTP 不一樣

許多人更喜歡將 HTTP 與 REST 進行比較。 REST 和 HTTP 不一樣。

休息！= HTTP

儘管 REST 還打算使 Web（互聯網）更加精簡和標準，但 Roy Fielding 提倡更嚴格地使用 REST 原則。這就是人們嘗試將 REST 與 Web 進行比較的地方。

Roy Fielding 在他的論文中沒有提到任何實現方向——包括任何協議偏好甚至 HTTP。到目前為止，我們都在遵守 REST 的六項指導原則，我們可以將其稱為我們的介面——RESTful。

五、總結

簡而言之，在 REST 架構風格中，數據和功能被視為資源，並使用統一資源標識符 (URI) 進行訪問。

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

客戶端和伺服器通過使用標準化的介面和協議來交換資源的表示。通常 HTTP 是最常用的協議，但 REST 並不強制要求它。

有關資源的元數據可用並用於控制緩存、檢測傳輸錯誤、協商適當的表示格式以及執行身份驗證或訪問控制。

最重要的是，與伺服器的每次交互都必須是無狀態的。

所有這些原則都有助於 RESTful 應用程式變得簡單、輕量和快速。

什麼是 rest api