首頁  >  文章  >  web前端  >  REST API 及其架構

REST API 及其架構

PHPz
PHPz原創
2024-09-08 20:33:07761瀏覽

簡介

在當今的 Web 開發世界中,API(應用程式介面)在實現不同軟體系統之間的通訊方面發揮著至關重要的作用。最廣泛使用的 API 類型之一是 REST API,它代表表述性狀態傳輸。 REST API 已成為建立可擴充、可維護且有效率的 Web 服務的標準。在這篇部落格中,我們將深入探討 REST API 是什麼、它們的原則、架構、元件以及如何有效地設計和實作它們。

什麼是 REST API?
REST(表述性狀態傳輸)是一種用於設計網路應用程式的架構風格。它依賴於無狀態的客戶端-伺服器通訊模型,並且基於標準 HTTP 方法。 REST API 允許不同的應用程式使用一組簡單的約定(或者我們可以說規則)透過網路進行通訊。

REST API and Its Architecture

REST API 是一個接口,允許客戶端(例如 Web 或行動應用程序,如我們的瀏覽器或手機)透過發送 HTTP 請求和接收 HTTP 回應與伺服器進行互動。伺服器提供對資源的訪問,資源可以是從用戶個人資料到圖像或部落格文章的任何內容。
休息的關鍵原則
要被視為 RESTful,API 必須具備以下六個原則:

  1. 客戶端-伺服器架構:客戶端和伺服器應該要互相獨立。客戶端負責使用者介面和使用者體驗,而伺服器則處理後端邏輯、資料儲存和處理。
  2. 無狀態性:從客戶端到伺服器的每個請求都必須包含瞭解和處理請求所需的所有資訊。伺服器在請求之間不儲存任何客戶端資訊。這使得伺服器設計更加合理並增強了可擴展性。
  3. 可緩存性:來自伺服器的回應必須明確定義為可快取或不可快取。如果回應是可快取的,客戶端可以在將來的請求中重複使用回應數據,從而減少伺服器的負載並提高效能。
  4. 統一介面:REST API 必須提供與資源互動的一致且標準化的方式。這是透過四個子原則來實現的:  - 資源識別:使用URI(統一資源標識符)來識別資源。  - 透過表示操作資源:客戶端透過在請求中傳送表示(例如 JSON、XML)來與資源互動。  - 自描述訊息:每個請求和回應必須包含足夠的資訊來描述如何處理訊息。  - 超媒體作為應用程式狀態引擎 (HATEOAS):用戶端應使用回應中提供的超連結動態導覽 API。
  5. 分層系統:架構應允許在客戶端和伺服器之間使用中間層,例如快取、負載平衡和安全層,而客戶端不知道這些層。
  6. 按需程式碼(可選):伺服器可以透過傳送要在客戶端執行的可執行程式碼(例如 JavaScript)來擴充客戶端功能。這是 REST 中的可選約束。

REST API 架構
REST API 的架構由幾個關鍵元件組成,這些元件協同工作以建立客戶端和伺服器之間的通訊:

  1. 資源:資源是 REST API 的核心概念。它們代表 API 提供存取的資料或對象,例如使用者、產品、訂單等。每個資源都由唯一的 URI 標識。

  2. HTTP 方法:REST API 使用標準 HTTP 方法對資源執行 CRUD(建立、讀取、更新、刪除)操作:
     - GET:從資源中擷取資料。
     - POST:在資源(DB)中建立新的資料變更。
     - PUT:更新資料(DB)中的現有記錄。
     - DELETE:從DB中刪除特定資料。
     - PATCH:部分更新現有資料。
     - 選項:檢索資源支援的 HTTP 方法。

  3. HTTP 狀態碼:REST API 使用標準 HTTP 狀態碼來指示請求的結果。常見的狀態代碼包括:
     - 200 OK:請求成功。
     - 201 Created:新資源創建成功。
     - 204 No Content:請求成功,但沒有內容可回傳。
     - 400 錯誤請求:請求格式錯誤或無效。
     - 401 未經授權:用戶端必須進行身份驗證才能存取資源。
     - 404 Not Found:未找到請求的資源。
     - 500 內部伺服器錯誤:伺服器發生意外錯誤。

  4. 表示格式:REST API 支援各種資料交換表示格式,包括 JSON(JavaScript 物件表示法)、XML(可擴充標記語言)和 HTML。 JSON 是最常用的格式,因為它簡單且與 JavaScript 相容。

  5. 端點:端點是定義可以從伺服器存取特定資源的位置的 URL。每個端點對應於一個特定的資源,通常使用名詞而不是動詞來設計(例如/users、/products)。

設計 RESTful API

設計 RESTful API 涉及多個步驟,以確保其遵守 REST 原則並為客戶提供無縫體驗。以下是設計 REST API 的一些最佳實踐:

  1. 對端點使用名詞:端點應以資源(名詞)而非運算(動詞)命名。例如,使用 /users 來表示使用者集合,而不是 /getUsers。

  2. 正確使用 HTTP 方法:為每個操作使用正確的 HTTP 方法。例如,使用 GET 檢索資料、POST 建立資料、PUT 更新資料、DELETE 刪除資料。

  3. 實現過濾、排序和分頁:對於傳回資源清單的端點,實現過濾、排序和分頁以提高效能並為客戶端提供更多控制。使用 ?sort=name、?page=2 或 ?limit=10 等查詢參數來實現此目的。

  4. 對 API 進行版本控制:請務必對 API 進行版本控制,以在不破壞現有客戶端的情況下處理變更。在 URL 中(例如 /api/v1/users)或標頭中包含版本號。

  5. 提供有意義的 HTTP 狀態碼:傳回適當的 HTTP 狀態碼以指示請求的結果。避免每次回覆都使用 200 OK。

  6. 使用超媒體 (HATEOAS):在回應中包含鏈接,以允許客戶端動態導航 API,而無需硬編碼 URL。

  7. 確保安全:使用 HTTPS 加密傳輸中的資料來保護您的 API。實施身份驗證(例如 OAuth、JWT)和授權來控制對資源的存取。

  8. 優雅地處理錯誤:提供有意義的錯誤訊息和 HTTP 狀態碼,以幫助客戶端了解出了什麼問題。建立可重複使用的錯誤格式,其中包含錯誤代碼、訊息和可能的解決方案等詳細資訊。

REST API 設計範例

讓我們考慮一個用於管理書籍集合的簡單 REST API 範例:

  1. 端點:/api/v1/books
  2. GET /api/v1/books:從 db 取得所有書籍的清單。  - POST /api/v1/books:在資料庫中建立一本新書。
  3. 端點:/api/v1/books/{id}
  4. GET /api/v1/books/{id}:按 ID 回傳特定書籍。  - PUT /api/v1/books/{id}:透過 ID 更新特定書籍。  - DELETE /api/v1/books/{id}:依ID刪除特定書籍
  5. 錯誤處理範例:
  6. 如果顧客要求一本不存在的書:   - 回應:404 未找到   - 身體:身體看起來像這樣

REST API and Its Architecture

實作 REST API

要實作 REST API,您可以使用各種程式語言和框架。以下是結合使用 Node.js 和 Express.js 的範例:

REST API and Its Architecture

以上是REST API 及其架構的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn