什么是 REST?

了解如何使用 REST 范例設(shè)計(jì) Web 服務(wù)

代表性狀態(tài)轉(zhuǎn)移

REST 或 REpresentational State Transfer 是一種架構(gòu)風(fēng)格，用于在 Web 上的計(jì)算機(jī)系統(tǒng)之間提供標(biāo)準(zhǔn)，使系統(tǒng)之間更容易相互通信。符合 REST 的系統(tǒng)，通常稱為 RESTful 系統(tǒng)，其特點(diǎn)是它們是無狀態(tài)的，并且將客戶端和服務(wù)器的關(guān)注點(diǎn)分開。我們將深入探討這些術(shù)語的含義以及為什么它們是 Web 服務(wù)的有益特征。

客戶端和服務(wù)器分離

在 REST 架構(gòu)風(fēng)格中，客戶端的實(shí)現(xiàn)和服務(wù)器的實(shí)現(xiàn)可以獨(dú)立完成，彼此不知道對(duì)方。這意味著客戶端的代碼可以隨時(shí)更改而不影響服務(wù)器的運(yùn)行，而服務(wù)器端的代碼可以更改而不影響客戶端的運(yùn)行。

只要雙方都知道要發(fā)送給對(duì)方的消息格式，它們就可以保持模塊化和分離。將用戶界面關(guān)注點(diǎn)與數(shù)據(jù)存儲(chǔ)關(guān)注點(diǎn)分開，我們提高了跨平臺(tái)界面的靈活性，并通過簡(jiǎn)化服務(wù)器組件來提高可擴(kuò)展性。此外，分離允許每個(gè)組件獨(dú)立發(fā)展的能力。

通過使用 REST 接口規(guī)范，不同的客戶端訪問相同的 REST 端點(diǎn)、執(zhí)行相同的操作并接收相同的響應(yīng)。

無國籍狀態(tài)

遵循 REST 范式的系統(tǒng)是無狀態(tài)的，這意味著服務(wù)器不需要知道客戶端處于什么狀態(tài)，反之亦然。這樣，服務(wù)器和客戶端都可以理解收到的任何消息，即使沒有看到以前的消息。這種無狀態(tài)約束是通過使用資源而不是命令來實(shí)現(xiàn)的。資源是 Web 的名詞——它們描述 了您可能需要存儲(chǔ)或發(fā)送到其他服務(wù)的任何對(duì)象、文檔或事物。

因?yàn)?REST 系統(tǒng)通過對(duì)資源的標(biāo)準(zhǔn)操作進(jìn)行交互，所以它們不依賴于接口的實(shí)現(xiàn)。

這些約束有助于 RESTful 應(yīng)用程序?qū)崿F(xiàn)可靠性、快速性能和可擴(kuò)展性，作為可以在不影響整個(gè)系統(tǒng)的情況下進(jìn)行管理、更新和重用的組件，即使在系統(tǒng)運(yùn)行期間也是如此。

現(xiàn)在，我們將探討在實(shí)現(xiàn) RESTful 接口時(shí)客戶端和服務(wù)器之間的通信是如何實(shí)際發(fā)生的。

客戶端和服務(wù)器之間的通信

在 REST 架構(gòu)中，客戶端發(fā)送請(qǐng)求以檢索或修改資源，服務(wù)器發(fā)送對(duì)這些請(qǐng)求的響應(yīng)。讓我們看一下發(fā)出請(qǐng)求和發(fā)送響應(yīng)的標(biāo)準(zhǔn)方法。

發(fā)出請(qǐng)求

REST 要求客戶端向服務(wù)器發(fā)出請(qǐng)求，以便檢索或修改服務(wù)器上的數(shù)據(jù)。請(qǐng)求通常包括：

一個(gè) HTTP 動(dòng)詞，它定義了要執(zhí)行的操作類型

一個(gè)標(biāo)頭，允許客戶端傳遞有關(guān)請(qǐng)求的信息

資源路徑

包含數(shù)據(jù)的可選消息正文

HTTP 動(dòng)詞

我們?cè)谡?qǐng)求中使用 4 個(gè)基本的 HTTP 動(dòng)詞來與 REST 系統(tǒng)中的資源進(jìn)行交互：

GET — 檢索特定資源(通過 id)或資源集合

POST — 創(chuàng)建一個(gè)新資源

PUT — 更新特定資源(按 id)

DELETE — 按 id 刪除特定資源

標(biāo)頭和接受參數(shù)

在請(qǐng)求的標(biāo)頭中，客戶端發(fā)送它能夠從服務(wù)器接收的內(nèi)容類型。這稱為Accept字段，它確保服務(wù)器不會(huì)發(fā)送客戶端無法理解或處理的數(shù)據(jù)

MIME 類型，用于指定Accept字段中的內(nèi)容類型，由 atype和 a組成subtype。它們由斜線 (/) 分隔。

例如，包含 HTML 的文本文件將被指定為 type text/html。如果此文本文件包含 CSS，則將其指定為text/css. 通用文本文件將表示為text/plain. 但是，此默認(rèn)值text/plain不是萬能的。如果客戶端期待text/css并接收text/plain，它將無法識(shí)別內(nèi)容。

其他類型和常用的亞型：

image— image/png, image/jpeg,image/gif

audio — audio/wav,audio/mpeg

video— video/mp4,video/ogg

application — application/json, application/pdf, application/xml,application/octet-stream

例如，客戶端訪問服務(wù)器上資源中具有id23 的articles資源可能會(huì)發(fā)送如下 GET 請(qǐng)求：

GET /articles/23

Accept: text/html, application/xhtml

在這種情況下，Accept標(biāo)頭字段表示客戶端將接受text/htmlor中的內(nèi)容application/xhtml。

路徑

請(qǐng)求必須包含指向應(yīng)該對(duì)其執(zhí)行操作的資源的路徑。在 RESTful API 中，應(yīng)該設(shè)計(jì)路徑以幫助客戶端了解正在發(fā)生的事情。

按照慣例，路徑的第一部分應(yīng)該是資源的復(fù)數(shù)形式。這使嵌套路徑易于閱讀和理解。

fashionboutique.com/customers/223/orders/12即使您以前從未見過此特定路徑，類似路徑的指向也很清楚，因?yàn)樗欠謱拥暮兔枋鲂缘摹Ｎ覀兛梢钥吹剑覀冋跒?23id的客戶訪問 12的訂單。id

路徑應(yīng)包含定位具有所需特異性程度的資源所需的信息。在引用資源列表或資源集合時(shí)，并不總是需要添加id. 例如，對(duì)fashionboutique.com/customers路徑的 POST 請(qǐng)求不需要額外的標(biāo)識(shí)符，因?yàn)榉?wù)器將為id新對(duì)象生成一個(gè)。

如果我們?cè)噲D訪問單個(gè)資源，我們需要id在路徑上附加一個(gè)。例如： GET fashionboutique.com/customers/:id— 檢索具有指定 的customers資源中的項(xiàng)目。— 刪除指定資源中的項(xiàng)目。idDELETE fashionboutique.com/customers/:idcustomersid

發(fā)送響應(yīng)

內(nèi)容類型

在服務(wù)器向客戶端發(fā)送數(shù)據(jù)有效負(fù)載的情況下，服務(wù)器必須content-type在響應(yīng)的標(biāo)頭中包含 a。此content-type標(biāo)頭字段提醒客戶端它在響應(yīng)正文中發(fā)送的數(shù)據(jù)類型。這些內(nèi)容類型是 MIME 類型，就像它們?cè)赼ccept請(qǐng)求標(biāo)頭的字段中一樣。服務(wù)器在響應(yīng)中發(fā)回的content-type應(yīng)該是客戶端在accept請(qǐng)求字段中指定的選項(xiàng)之一。

例如，當(dāng)客戶端使用此 GET 請(qǐng)求訪問資源中的id23資源時(shí)：articles。

GET /articles/23 HTTP/1.1
Accept: text/html, application/xhtml

服務(wù)器可能會(huì)發(fā)送回帶有響應(yīng)頭的內(nèi)容：

HTTP/1.1 200 (OK)
Content-Type: text/html

這表示請(qǐng)求的內(nèi)容在響應(yīng)正文中以content-typeof形式返回text/html，客戶端表示它能夠接受。

響應(yīng)代碼

來自服務(wù)器的響應(yīng)包含狀態(tài)代碼以提醒客戶端有關(guān)操作成功的信息。作為開發(fā)人員，您不需要知道每個(gè)狀態(tài)碼(其中有很多)，但您應(yīng)該知道最常見的狀態(tài)碼以及它們的使用方式：

對(duì)于每個(gè) HTTP 動(dòng)詞，服務(wù)器應(yīng)在成功時(shí)返回預(yù)期的狀態(tài)代碼：

GET — 返回 200(確定)

POST — 返回 201(已創(chuàng)建)

PUT——返回 200(OK)

DELETE — 返回 204 (NO CONTENT) 如果操作失敗，返回與遇到的問題相對(duì)應(yīng)的最具體的狀態(tài)碼。

請(qǐng)求和響應(yīng)示例

假設(shè)我們有一個(gè)應(yīng)用程序，允許您查看、創(chuàng)建、編輯和刪除托管在小型服裝店的客戶和訂單fashionboutique.com。我們可以創(chuàng)建一個(gè)允許客戶端執(zhí)行這些功能的 HTTP API：

如果我們想查看所有客戶，請(qǐng)求將如下所示：

GET http://fashionboutique.com/customers
Accept: application/json

可能的響應(yīng)標(biāo)頭如下所示：

Status Code: 200 (OK)
Content-type: application/json

其次是格式customers要求的數(shù)據(jù)application/json。

通過發(fā)布數(shù)據(jù)創(chuàng)建新客戶：

POST http://fashionboutique.com/customers
Body:
{
  “customer”: {
    “name” = “Scylla Buss”,
    “email” = “[email protected]”
  }
}

然后，服務(wù)器id為該對(duì)象生成一個(gè)并將其返回給客戶端，其標(biāo)頭如下：

201 (CREATED)
Content-type: application/json

要查看單個(gè)客戶，我們通過指定該客戶的 id 來獲取它：

GET http://fashionboutique.com/customers/123
Accept: application/json

可能的響應(yīng)標(biāo)頭如下所示：

Status Code: 200 (OK)
Content-type: application/json

后面是格式為23的customer資源數(shù)據(jù)。idapplication/json

我們可以通過PUT新數(shù)據(jù)更新該客戶：

PUT http://fashionboutique.com/customers/123
Body:
{
  “customer”: {
    “name” = “Scylla Buss”,
    “email” = “[email protected]”
  }
}

可能的響應(yīng)標(biāo)頭將具有Status Code: 200 (OK), 以通知客戶端帶有id123 的項(xiàng)目已被修改。

我們還可以通過指定其刪除該客戶id：

DELETE http://fashionboutique.com/customers/123

響應(yīng)將有一個(gè)包含 的標(biāo)頭Status Code: 204 (NO CONTENT)，通知客戶端帶有id123 的項(xiàng)目已被刪除，而正文中沒有任何內(nèi)容。如果大家想了解更多相關(guān)知識(shí)，可以關(guān)注一下動(dòng)力節(jié)點(diǎn)的Java在線學(xué)習(xí)，里面的課程內(nèi)容從入門到精通，很適合沒有基礎(chǔ)的小伙伴學(xué)習(xí)，希望對(duì)大家能夠有所幫助。