當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

restful rest_HATEOAS的RESTful服务。 REST：刷新器

發(fā)布時間：2023/12/3 编程问答 34 豆豆

生活随笔收集整理的這篇文章主要介紹了 restful rest_HATEOAS的RESTful服务。 REST：刷新器小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

restful rest

在這篇文章中，我們將介紹有關(guān)HATEOAS的RESTful服務(wù)的綜合文章。 REST：刷新器。

1.簡介

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

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

那么，這本書的背后的想法是什么？本教程的唯一目的是重溫根源，重新考慮遵循REST體系結(jié)構(gòu)樣式設(shè)計和實現(xiàn)Web API的含義，以及如何在Java服務(wù)和應(yīng)用程序中或通常在JVM平臺上實際實現(xiàn)Web API。。

2. REST體系結(jié)構(gòu)約束

代表性狀態(tài)轉(zhuǎn)移（或簡稱REST ）不是規(guī)范，而是體系結(jié)構(gòu)樣式，指導(dǎo)分布式軟件系統(tǒng)設(shè)計的一組原則和約束。按照REST架構(gòu)風(fēng)格設(shè)計的系統(tǒng)必須符合五個強(qiáng)制性（和一個可選性）約束。讓我們簡要瀏覽一下它們。

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

無狀態(tài)
客戶端和服務(wù)器之間的通信應(yīng)該是無狀態(tài)的。實際上，這意味著從客戶端到服務(wù)器的每個請求都必須包含處理該請求所需的所有信息。服務(wù)器不應(yīng)存儲任何與會話相關(guān)的狀態(tài)或上下文，因此客戶端是負(fù)責(zé)管理該狀態(tài)或上下文的服務(wù)器。通常將這一原理作為構(gòu)建可靠的和水平可伸縮系統(tǒng)的必要先決條件。

快取
服務(wù)器必須能夠向客戶端提示響應(yīng)中的數(shù)據(jù)是否可以緩存。高效的緩存實現(xiàn)可以減少服務(wù)器的不必要負(fù)擔(dān)，提高整體可伸縮性，并顯著減少網(wǎng)絡(luò)交互的延遲。

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

統(tǒng)一界面
在我們的討論中，這可能是最重要的體系結(jié)構(gòu)原理，它強(qiáng)調(diào)組件之間存在統(tǒng)一接口。反過來，它概述了此類接口應(yīng)遵循的五個約束：
- 資源識別

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

為了進(jìn)一步加強(qiáng)它， REST為架構(gòu)師和系統(tǒng)設(shè)計了一套原則和約束，但這絕不是實現(xiàn)。

3. REST！=通過HTTP進(jìn)行RPC

REST體系結(jié)構(gòu)樣式不會將客戶端/服務(wù)器通信限制為特定協(xié)議。但是，如今，它主要用于構(gòu)建通過HTTP （ Web協(xié)議）進(jìn)行通信的Web API和服務(wù)。

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

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

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

它總結(jié)了業(yè)界對REST體系結(jié)構(gòu)樣式采用的悲觀狀態(tài)。是的，它似乎無處不在，但是不幸的是，大多數(shù)Web應(yīng)用程序使用RPC樣式而不是遵循REST明確定義的約束（尤其是統(tǒng)一接口 ）通過HTTP在HTTP上公開了這些API和服務(wù)。

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

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

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

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

但是，我認(rèn)為大多數(shù)人都犯了一個錯誤：設(shè)計簡單的東西應(yīng)該很簡單。實際上，設(shè)計某些東西所需的工作與結(jié)果的簡單程度成反比。隨著建筑風(fēng)格的發(fā)展，REST非常簡單。

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

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

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

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

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

4.巨大的困惑：RESTful與REST

由于許多組織和個人正在使用自己對REST的解釋來構(gòu)建Web服務(wù)和API，因此導(dǎo)致人們對哪種應(yīng)用程序和系統(tǒng)實際上遵循REST體系結(jié)構(gòu)風(fēng)格感到困惑。為了使這種區(qū)別顯而易見， RESTful這個術(shù)語誕生了。

遵守REST體系結(jié)構(gòu)約束的 Web服務(wù)API稱為RESTful API。

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

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

要使REST體系結(jié)構(gòu)風(fēng)格清晰地認(rèn)識到超文本是一種約束，需要采取什么措施？換句話說，如果應(yīng)用程序狀態(tài)的引擎（以及API）不是由超文本驅(qū)動的，則它不能是RESTful的，也不能是REST API。期。是否有一些需要修復(fù)的故障手冊？

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

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

5.理查森成熟度模型

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

理查森API成熟度模型

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

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

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

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

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

有了這個成熟度模型，每當(dāng)您聽到“……在我們組織中，我們構(gòu)建暴露REST Web API的應(yīng)用程序……”時，我們很可能在談?wù)?strong>Level 2 。

6. RESTful服務(wù)–結(jié)論

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

通過包含超文本的自描述消息的統(tǒng)一接口提供基于網(wǎng)絡(luò)的資源訪問的API，該消息包含超文本以指示潛在的狀態(tài)轉(zhuǎn)換，它可能是RESTful應(yīng)用程序的整個系統(tǒng)的一部分

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

在本教程的后續(xù)部分中，我們將大部分時間花在談?wù)揌ATEOAS上，這可能是所有聲稱被稱為真正的RESTful的 API中最困難但也是功??能最強(qiáng)大的元素。

7.接下來

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

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