restful rest

在這篇文章中，我們將介紹有關HATEOAS的RESTful服務的綜合文章。 REST：刷新器。

1.簡介

“不好了！ 請，不要再發表有關REST的文章！” 你們中的許多人可能會尖叫，這是正確的。 已經出版了太多的教程，帖子，討論和最佳實踐，而再提出一個幾乎沒有任何意義。

坦白地說，對REST的理解因人而異。 并非每個人都有時間（也有愿望）閱讀Roy Fielding優秀論文的“ 代表性狀態轉移”（REST）一章，因此，對于許多REST而言 ，無論其含義如何，它基本上都是基于HTTP的API的代名詞。 但是， REST的一面大部分時間都處于黑暗中，毫無根據地被遺忘和忽略： 超媒體 。

目錄

1.簡介 2. REST體系結構約束 3. REST！=通過HTTP進行RPC 4.巨大的困惑：RESTful與REST 5.理查森成熟度模型 6。結論 7.接下來

那么，這本書的背后的想法是什么？ 本教程的唯一目的是重溫根源，重新考慮遵循REST體系結構樣式設計和實現Web API的含義，以及如何在Java服務和應用程序中或通常在JVM平臺上實際實現Web API。 。

2. REST體系結構約束

代表性狀態轉移 （或簡稱REST ）不是規范，而是體系結構樣式，指導分布式軟件系統設計的一組原則和約束。 按照REST架構風格設計的系統必須符合五個強制性（和一個可選性）約束。 讓我們簡要瀏覽一下它們。

• 客戶端服務器
  在微服務時代，這聽起來很明顯。 但是，只是為了重申這一基本原理，客戶端和服務器是相互分離的。 這樣，每一方都有能力和機會獨立發展。

• 無狀態
  客戶端和服務器之間的通信應該是無狀態的。 實際上，這意味著從客戶端到服務器的每個請求都必須包含處理該請求所需的所有信息。 服務器不應存儲任何與會話相關的狀態或上下文，因此客戶端是負責管理該狀態或上下文的服務器。 通常將這一原理作為構建可靠的和水平可伸縮系統的必要先決條件。

• 快取
  服務器必須能夠向客戶端提示響應中的數據是否可以緩存。 高效的緩存實現可以減少服務器的不必要負擔，提高整體可伸縮性，并顯著減少網絡交互的延遲。

• 分層系統
  這又一個基本原則主張將體系結構設計為由層次結構層組成。 在客戶端/服務器通信方面，客戶端無法確定它是直接連接到服務器還是通過任何中介連接（首先想到的這種中介是負載均衡器）。

• 統一界面
  在我們的討論中，這可能是最重要的體系結構原理，它強調組件之間存在統一接口。 反過來，它概述了此類接口應遵循的五個約束：
  • 資源識別

• 按需編碼（可選）
  此可選約束建議可以通過從服務器下載并執行一些代碼來擴展客戶端功能。

為了進一步加強它， REST為架構師和系統設計了一套原則和約束，但這絕不是實現。

3. REST！=通過HTTP進行RPC

REST體系結構樣式不會將客戶端/服務器通信限制為特定協議。 但是，如今，它主要用于構建通過HTTP （ Web協議）進行通信的Web API和服務。

在這種情況下，使用URL標識各個資源。 JSON或XML是表示資源的兩種主要格式，而客戶端可以使用適當的HTTP動詞來操縱資源。 坦白地說，大多數Web API設計人員和實施人員就此止步，根本沒有提及HATEOAS 。 所有這些人是否會誤解REST的含義？ 羅伊·菲爾丁 （ Roy Fielding）在他的一條推文中很好地總結了這一點：

我不同意這個術語的流行理解是不同的。 不同的是某些公司，作者和發言人希望在知道僅是HTTP時說REST； 不是因為他們不知道該術語的含義，而是因為$$$ >>的含義。

https://twitter.com/fielding/status/1108092713516163072?lang=zh-CN

它總結了業界對REST體系結構樣式采用的悲觀狀態。 是的，它似乎無處不在，但是不幸的是，大多數Web應用程序使用RPC樣式而不是遵循REST明確定義的約束（尤其是統一接口 ）通過HTTP在HTTP上公開了這些API和服務。

這是為什么？ 可能的部分原因是， REST體系結構樣式提到了超媒體和HATEOAS，但并未真正說明必須完成的精確度（考慮了客戶端和服務器之間可能發生的所有復雜交互）。

在某種程度上，人們誤解了REST，因為我沒有在論文中包含關于媒體類型設計的足夠細節。 那是因為我沒時間了，不是因為我認為它比REST的其他方面都重要。

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

同樣，對于許多人來說，不僅要設計資源命名，表示，語義和操作，而且還要設計狀態轉換（甚至不涉及測試所有主題），似乎是一筆不小的開銷。

但是，我認為大多數人都犯了一個錯誤：設計簡單的東西應該很簡單。 實際上，設計某些東西所需的工作與結果的簡單程度成反比。 隨著建筑風格的發展，REST非常簡單。

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

我認為遵循REST架構風格值得付出努力。 是的，您可能不知所措。 是的，由于不適合您的編程語言或平臺的工具和庫，您可能會面臨很多挑戰，尤其是在超媒體方面 。 另一方面，您最終將獲得描述性強，易于理解和可維護的Web服務和API。

在輸入REST API之前，除了初始URI （書簽）和適用于目標受眾的標準媒體類型集（即，期望使用該API的任何客戶端可以理解的標準媒體類型）外，都應該沒有其他知識。 從那時起，所有應用程序狀態轉換都必須由客戶端選擇服務器提供的選擇來驅動，這些選擇出現在接收到的表示中或由用戶對這些表示的操縱來暗示。 過渡可以由客戶端對媒體類型和資源通信機制的了解來確定（或受其限制），這兩者都可以動態地（例如，按需編碼）進行改進。

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-超文本驅動

希望在本教程的過程中，我們將揭穿一些神話，并以實際方式證明HATEOAS支持的Web服務和API是可行的，而且并不難。

4.巨大的困惑：RESTful與REST

由于許多組織和個人正在使用自己對REST的解釋來構建Web服務和API，因此導致人們對哪種應用程序和系統實際上遵循REST體系結構風格感到困惑。 為了使這種區別顯而易見， RESTful這個術語誕生了。

遵守REST體系結構約束的 Web服務API稱為RESTful API。

https://zh.wikipedia.org/wiki/Representational_state_transfer

本質上，此定義沒有余地：滿足所有必需的約束 ，或者請不要將您的API稱為RESTful 。 毫不奇怪， 羅伊·菲爾丁 （ Roy Fielding）對這件事有更嚴格的意見。

要使REST體系結構風格清晰地認識到超文本是一種約束，需要采取什么措施？ 換句話說，如果應用程序狀態的引擎（以及API）不是由超文本驅動的，則它不能是RESTful的 ，也不能是REST API。 期。 是否有一些需要修復的故障手冊？

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-超文本驅動

本教程的目的是展示HATEOAS是頭等公民的RESTful API設計以及所有其他必需的約束。 不，我們不會將REST視為宗教，而是要證明每個元素都很重要而且存在是有原因的。

5.理查森成熟度模型

REST保護下的Web服務和API的碎片要求采取行動。 作為響應， 倫納德·理查森 （ Leonard Richardson）開發了API成熟度模型（通常簡稱為Richardson成熟度模型 ），該模型實質上定義了4個級別的API成熟度。

理查森API成熟度模型

這個非常簡單的模型有助于輕松地確定特定Web API在實現RESTful方面所處的位置（請注意，每個級別都基于其下一個級別）。 您可能還會注意到，該模型并非普遍適用，而是明確關注基于HTTP協議的REST （我們記得， REST體系結構風格與基礎網絡協議無關）。

• 0級– POX沼澤
  最底層是使用HTTP協議進行遠程交互以隧道請求和響應的Web API。 通常，他們使用單個HTTP方法（通常是POST ）并公開單個API入口點。 這是典型的RPC over HTTP樣式。

• 級別1 –資源
  稍微成熟一些，我們會遇到一些Web API，這些API公開了多個入口點，或者遵循REST命名法提供了單獨的資源。 當然可以，但是這些API仍使用單個HTTP方法（通常是POST ）。

• 2級– HTTP動詞
  為了更進一步地遵守RESTful原則，此級別的Web API使用HTTP謂詞語義來區分各個資源上的不同動作。 這是大多數現代Web API最終達到的級別，聲稱“足夠好”。

• 3級–超媒體控件
  在最頂層，我們遇到了使用HATEOAS和超媒體控件來引導客戶端/服務器交互的Web API。 在此級別上，API可以稱為真正的RESTful 。

有了這個成熟度模型，每當您聽到“……在我們組織中，我們構建暴露REST Web API的應用程序……”時，我們很可能在談論Level 2 。

6. RESTful服務–結論

在本教程的介紹性部分中，我們更新了對REST體系結構樣式的了解，尤其是重新介紹了其強制性原則和約束。 我們還揭開了RESTful一詞的起源以及它如何應用于現代Web API和服務的神秘感。 再一次， 羅伊·菲爾丁 （ Roy Fielding）將其牢牢地釘牢了。

通過包含超文本的自描述消息的統一接口提供基于網絡的資源訪問的API，該消息包含超文本以指示潛在的狀態轉換，它可能是RESTful應用程序的整個系統的一部分

https://twitter.com/fielding/status/1125438763507654658

在本教程的后續部分中，我們將大部分時間花在談論HATEOAS上 ，這可能是所有聲稱被稱為真正的RESTful的 API中最困難但也是功??能最強大的元素。

7.接下來

在本教程的下一部分中，我們將開始討論使用HATEOAS功能豐富您的Web服務和API的多種方法。

翻譯自: https://www.javacodegeeks.com/restful-services-with-hateoas-rest-the-refresher.html

restful rest

總結

以上是生活随笔為你收集整理的restful rest_HATEOAS的RESTful服务。 REST：刷新器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。