REST 概述。第 2 部分：客戶端和服務器之間的通信

REST 概述。第 1 部分：什麼是 REST？在這一部分中，我們將深入探討客戶端和服務器之間如何進行通信。在此過程中，我們將發現新術語並對其進行解釋。 REST 概述。第 2 部分：客戶端和服務器之間的通信 - 1

為了確保一切都清楚，我們將使用 RESTful 應用程序作為示例來分析客戶端-服務器通信。假設我們正在開發一個 Web 應用程序來存儲有關客戶及其訂單的信息。換句話說，我們的系統能夠對某些實體執行操作：創建、編輯和刪除它們，並顯示有關它們的信息。這些實體將是：

客戶（客戶）
訂單（客戶訂單）
項目（產品）

在 RESTful 架構中，客戶端向服務器發送請求以檢索或修改數據，然後服務器向客戶端發送對其請求的響應。

要求

客戶端請求幾乎總是使用 HTTP 協議進行的。通常，HTTP 請求由幾個部分組成：

HTTP方法
標頭
網址
請求正文

下面我們將更詳細地考慮每個組件。

URI 和資源

客戶端通過請求接收或修改的數據稱為資源。客戶端-服務器通信都是關於操縱資源的。在 REST 中，資源是您可以為其命名的任何東西。從某種意義上說，它們就像 Java 中的類。在 Java 中，我們可以為任何東西創建一個類。所以在 REST 中，資源可以是任何東西：用戶、文檔、報告、訂單。它可以是某個實體的抽象，也可以是特定的東西，例如圖像、視頻、動畫或 PDF 文件。在我們的示例中，我們有 3 個資源：

客戶（客戶）
訂單（客戶訂單）
項目（產品）

客戶端將請求發送到稱為端點的資源位置。簡而言之，端點就像網絡上的地址。深入研究，我們可以說端點是一個URI，即標識抽像或物理資源的字符序列。統一資源標識符 (URI) 有時端點或 URI 稱為路徑，表示資源的路徑。出於本文的目的，我們將使用術語 URI。每個特定資源都必須具有唯一的 URI。服務器開發人員負責確保每個資源始終具有自己的 URI。在我們的示例中，我們是開發人員，因此我們將按照我們知道的方式進行。正如通常習慣將數字標識符指定為關係數據庫中的主鍵一樣，每個資源在 REST 中也有自己的 ID。REST 中的資源 ID 通常與存儲資源信息的數據庫中記錄的 ID 相匹配。REST URI 通常以描述某些資源的名詞的複數形式開頭。例如， ”

/customers — 所有可用客戶的 URI
/customers/23 — 特定客戶的 URI，即 ID=23 的客戶
/customers/4 — 特定客戶的 URI，即 ID=4 的客戶。

但這還不是全部。我們可以通過添加命令來擴展 URI：

/customers/4/orders — 第 4 位客戶下的所有訂單的 URI
/customers/1/orders/12 — 1 號客戶製作的 12 號訂單的 URI。

如果我們通過添加更多產品來繼續擴展，我們會得到：

/customers/1/orders/12/items — 1 號客戶製作的 12 號訂單中所有產品列表的 URI。

當我們添加嵌套級別時，重要的是使 URI 直觀。

HTTP方法

HTTP 方法是任意字符（控製字符和定界符除外）的序列，表示對資源執行的主要操作。有幾種常見的 HTTP 方法。我們將列出 RESTful 服務中最常用的那些：

GET — 獲取有關特定資源（通過其 ID）或資源集合的信息
POST——創建一個新資源
PUT — 更改資源（通過其 ID）
DELETE — 刪除資源（通過其 ID）

標頭

請求和響應都包含 HTTP 標頭。它們傳達有關請求（或響應）的附加信息。標頭是鍵值對。您可以在維基百科上查看最常見的標題列表。對於 REST，客戶端通常會在請求中向服務器發送一個“Accept”標頭。需要此標頭來告訴服務器客戶端希望以何種格式接收響應。MIME 類型列表中給出了各種格式。 MIME（多用途 Internet 郵件擴展）是一種編碼信息和格式化消息的規範，因此它們可以通過 Internet 發送。每個 MIME 類型都由斜線分隔的兩部分組成 — 類型和子類型。不同類型文件的 MIME 類型示例：

text — text/plain, text/css, text/html
圖像 — 圖像/png、圖像/jpeg、圖像/gif
音頻 — 音頻/wav，音頻/mpeg
視頻 — 視頻/mp4，視頻/ogg
application — application/json, application/pdf, application/xml, application/octet-stream

例如，一個請求可以有一個像這樣的標題：


Accept:application/json

此標頭告訴服務器客戶端希望收到 JSON 格式的響應。

請求正文

這是客戶端發送給服務器的消息。請求是否有主體取決於 HTTP 請求的類型。例如，GET 和 DELETE 請求一般不包含任何請求體。但是 PUT 和 POST 請求可以——這只取決於請求的目的。畢竟，要使用 ID（在 URL 中傳遞）接收和/或刪除數據，您不需要向服務器發送額外的數據。但是為了創建新資源（通過 POST 請求），您需要發送資源。修改現有資源也是如此。在 REST 中，請求主體通常以 XML 或 JSON 格式發送。JSON 格式是最常見的。假設我們要向服務器發送請求以創建新資源。如果你還沒有忘記，我們考慮了管理客戶訂單的應用程序示例。假設我們要創建一個新客戶。在我們的案例中，我們存儲以下客戶信息：姓名、電子郵件、電話號碼。然後請求的主體可以是以下 JSON：


{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

將請求放在一起

因此，我們已經檢查了客戶請求中可能包含的內容。我們現在將給出一些請求示例以及描述

要求	描述
`GET /customers/23 Accept : application/json, application/xml`	以 JSON 或 XML 格式獲取有關 23 號客戶的信息
`POST /customers { "name" : "Amigo", "email" : "amigo@jr.com", "phone" : "+1 (222) 333-4444" }`	使用以下字段創建一個新客戶：姓名 — Amigo 電子郵件 — amigo@jr.com 電話號碼 — +1 (222) 333-4444
`PUT /customers/1 { "name" : "Ben", "email" : "bigben@jr.com", "phone" : "+86 (868) 686-8686" }`	編輯 1 號客戶如下：姓名 — Ben 電子郵件 — bigben@jr.com 電話號碼 — +86 (868) 686-8686
`DELETE /customers/12/orders/6`	從系統中刪除客戶 12 下的 6 號訂單