休息概述。第2部分：客戶端和伺服器之間的通信

第 1 部分：什麼是 REST 在這一部分中，我們將仔細研究客戶端和伺服器之間如何進行通訊。在此過程中，我們將揭示新術語並對其進行解釋。 為了讓一切變得清晰，我們將使用一些 RESTful 應用程式的範例來分析客戶端-伺服器通訊。假設我們正在開發一個能夠儲存有關客戶及其訂單資訊的 Web 應用程式。那些。我們的系統能夠操縱一些實體：創建它們、編輯它們、刪除它們以及提供有關它們的資訊。這些實體將是：

• 客戶——客戶；
• 訂單——客戶訂單；
• 物品——貨物。

在 REST 架構中，客戶端向伺服器發送請求以獲取或修改數據，伺服器向客戶端發送對其請求的回應。

要求

客戶端請求幾乎總是透過 HTTP 發出。一般來說，HTTP 請求由以下幾個部分組成：

• HTTP 方法；
• 標題;
• 統一資源定位符；
• 請求正文。

下面我們將更詳細地了解每個組成部分。

URI 和資源

客戶端透過請求獲取或修改的資料稱為資源。客戶端-伺服器互動的基礎是資源的操作。 REST 中的資源是任何可以命名的東西。從某種意義上說，它們就像 Java 中的類別。在 Java 中，我們可以為任何東西建立一個類別。在 REST 中也是一樣 - 資源可以是任何東西：使用者、文件、報告、訂單。所有這些可以是某個實體的抽象，也可以是具體的東西，例如檔案 - 圖片、影片、動畫、PDF 檔案。對於我們的範例，我們有 3 個資源：

• 客戶——客戶；
• 訂單——客戶訂單；
• 物品——貨物。

客戶端將請求發送到所謂的端點或終點。簡而言之，端點就像網路上的位址。更深入地說，端點是一個 URI：標識抽像或物理資源的字元序列。Uniform Resource Identifier - 統一資源識別碼。有時，端點或 URI 稱為路徑 - 資源的路徑。出於本文的目的，我們將使用術語 URI。每個特定資源必須有一個唯一的 URI。確保每個資源始終具有自己的 URI 的責任落在伺服器開發人員的肩上。在我們的範例中，我們是開發人員，因此我們將以我們知道的方式來做。就像在關聯式資料庫中通常習慣將主鍵設為某個數字 ID 一樣，在 REST 中每個資源都有自己的 ID。通常，REST 中資源的 ID 與儲存該資源資訊的資料庫中的記錄 ID 相符。REST URI 通常以描述某些資源的名詞的複數形式開頭。例如，來自“客戶”一詞。接下來，透過斜線表示 ID－特定客戶端的識別碼。例子：

• /clients - 所有現有客戶端的 URI；
• /clients/23 - 特定客戶端的URI，即ID=23的客戶端；
• /clients/4 - 特定客戶端的URI，即ID=4的客戶端。

但這還不是全部。我們可以透過新增命令來擴展 URI：

• /clients/4/orders — 4號客戶端所有訂單的URI；
• /clients/1/orders/12 - 1號客戶的12號訂單的URI。

如果我們繼續這個鏈條並添加商品，我們會得到：

• /clients/1/orders/12/items — 1 號客戶製作的 12 號訂單中所有產品清單的 URI。

對於巢狀級別，關鍵是使 URI 直觀。

HTTP方式

HTTP Method（英文HTTP Method）是控制項和分隔符號以外的任意字元的序列，它指示資源的主要操作。有幾種常見的 HTTP 方法。我們列出了 RESTful 服務中最常使用的那些：

• GET－用於取得特定資源（透過ID）或資源集合的資訊；
• POST－用於建立新資源；
• PUT - 用於更改資源（透過 ID）；
• DELETE - 用於刪除資源（透過 ID）。

標題

請求和回應都包含 HTTP 標頭。他們發送有關請求（或回應）的附加資訊。標頭是鍵值對。您可以在維基百科頁面上閱讀最常見標題的清單。使用 REST，客戶端通常可以在其請求中向伺服器發送 Accept 標頭。需要讓伺服器知道客戶端期望以什麼格式接收其回應。所謂的 MIME 類型清單中提供了各種格式選項。 MIME（多用途網路郵件擴充）是一種將資訊編碼和格式化訊息以便可以透過網路傳送的規範。每個 MIME 類型由兩個部分組成，以斜線分隔：類型和子類型。不同類型檔案的 MIME 類型範例：

• 文字 - 文字/純文字、文字/css、文字/html；
• 圖像 - 圖像/png、圖像/jpeg、圖像/gif；
• 音訊 - 音訊/wav、音訊/mpeg；
• 視訊 - 視訊/mp4、視訊/ogg；
• 應用程式 - 應用程式/json、應用程式/pdf、應用程式/xml、應用程式/八位元組流。

總的來說，請求可能具有以下標頭：

Accept:application/json

該標頭告訴伺服器客戶端希望收到 JSON 格式的回應。

請求正文

客戶端向伺服器發送的訊息。請求是否有正文取決於 HTTP 請求的類型。例如，GET 和 DELETE 請求通常不包含任何請求正文。但 PUT 和 POST 可以包含：這一切都與請求類型的功能目的有關。畢竟，要透過 id（在 URL 中傳輸）接收資料並刪除它，不需要向伺服器發送額外的資料。但要建立新資源（POST 請求），您需要傳輸此資源。修改現有資源也是如此。在 REST 中，最常使用 XML 或 JSON 格式來傳送請求正文。最常見的格式是 JSON。假設我們要向伺服器發送請求，並在其中建立一個新資源。如果您還記得，作為範例，我們查看了一個管理客戶訂單的應用程式。假設我們要建立一個新客戶端。在我們的例子中，我們儲存有關客戶的以下資訊： 姓名 電子郵件 電話號碼 那麼此類請求的正文可能是以下 JSON：

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

將請求放在一起

因此，我們研究了客戶端請求可以包含哪些內容。現在讓我們給一些帶有描述的查詢範例

答案

讓我們簡單介紹一下伺服器的回應。答案通常由以下部分組成：

• 響應代碼；
• 標頭；
• 響應體。

一般來說，回應標頭與請求標頭沒有太大區別。此外，某些標頭同時用於回應和請求。我認為響應正文中的一切也很清楚。正文通常傳回客戶端請求的訊息。對於 GET 請求，可以以相同的 JSON 格式傳回訊息。但最後一部分更有趣一些。

HTTP 回應碼

讓我們仔細看看 HTTP 回應代碼。以下是維基百科的引用： HTTP 狀態代碼是透過 HTTP 協定請求的伺服器回應的第一行的一部分。它是一個有三位小數的整數。第一個數字表示狀況的類別。回應代碼後面通常是由空格分隔的英文解釋性短語，向使用者解釋此特定回應的原因。例子：

• 201 創建；
• 401 未經授權；
• 507 儲存空間不足。

客戶端從回應代碼中了解其請求的結果，並確定下一步要採取的操作。回應代碼分為幾組：

• 1ХХ - 資訊性；
• 2ХХ - 告知成功接受和處理客戶請求的案例；
• 3XX－通知客戶端為了成功完成操作，需要再次發出請求，通常使用不同的URI；
• 4ХХ - 客戶端錯誤。例如，錯誤建構的請求或眾所周知的 404 Not Found 程式碼，當客戶端請求不存在的資源時可能會發生這種情況；
• 5ХХ - 伺服器錯誤。如果由於伺服器故障導致操作失敗，則傳回給客戶端。

您可以在此處閱讀有關所有代碼的更多資訊。 第 1 部分：什麼是 REST 第 3 部分：在 Spring Boot 中建立 RESTful 服務