當(dāng)前位置：首頁 >

rest开发_REST 101开发人员专用

發(fā)布時(shí)間：2023/12/3 50 豆豆

生活随笔收集整理的這篇文章主要介紹了 rest开发_REST 101开发人员专用小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

rest開發(fā)

本地代碼執(zhí)行

諸如C之類的高級語言中的函數(shù)將被匯編為Assembly中的過程。它們增加了一個(gè)間接級別，使我們不必考慮內(nèi)存地址。

諸如Java之類的面向?qū)ο笳Z言中的方法和多態(tài)性增加了另一種間接性，使我們不必考慮一組相似功能的特定變體。

盡管有這些間接性，方法基本上仍然是過程調(diào)用，告訴計(jì)算機(jī)將執(zhí)行流從一個(gè)內(nèi)存位置切換到另一個(gè)內(nèi)存位置。所有這些都是在同一臺計(jì)算機(jī)上運(yùn)行的同一進(jìn)程中發(fā)生的。

遠(yuǎn)程執(zhí)行代碼

這與將執(zhí)行切換到另一個(gè)進(jìn)程或另一臺計(jì)算機(jī)根本不同。特別是后者非常不同，因?yàn)榱硪慌_計(jì)算機(jī)甚至可能沒有相同的操作系統(tǒng)，程序可以通過該操作系統(tǒng)訪問內(nèi)存。

因此，嘗試盡可能隱藏這種差異的遠(yuǎn)程代碼執(zhí)行機(jī)制（例如RMI或SOAP ）在很大程度上失敗并不奇怪。這種技術(shù)采用了所謂的遠(yuǎn)程過程調(diào)用（RPC）。

我們必須區(qū)分本地過程調(diào)用和遠(yuǎn)程過程調(diào)用的原因之一是RPC的速度慢得多。

對于大多數(shù)實(shí)際應(yīng)用程序，這將改變您進(jìn)行的調(diào)用的性質(zhì)：您將希望進(jìn)行較少的遠(yuǎn)程調(diào)用，而這些調(diào)用的粒度更粗。

另一個(gè)原因是本質(zhì)上組織性比技術(shù)性強(qiáng)。

當(dāng)您調(diào)用的代碼位于另一臺計(jì)算機(jī)上的另一個(gè)進(jìn)程中時(shí)，該另一個(gè)進(jìn)程很可能是由其他人編寫和部署的。為了使這兩段代碼很好地協(xié)作，需要某種形式的協(xié)調(diào)。這就是我們?yōu)轳詈细冻龅拇鷥r(jià)。

通過接口協(xié)調(diào)變更

我們還可以在單??個(gè)過程中看到此問題，例如，當(dāng)代碼部署在不同的jar文件中時(shí)。如果升級代碼所依賴的第三方j(luò)ar文件，則可能需要更改代碼以使一切正常運(yùn)行。

這種協(xié)調(diào)令人討厭。如果我們只需部署該jar的最新安全補(bǔ)丁程序而不必?fù)?dān)心破壞我們的代碼，那就更好了。幸運(yùn)的是，如果我們謹(jǐn)慎的話，我們可以。

Java之類的語言接口將代碼的公共部分和私有部分分開。

客戶所依賴的是公共部分，因此您必須以謹(jǐn)慎的方式開發(fā)接口，以避免破壞客戶。

相反，私有部分可以隨意更改。

從界面到服務(wù)

在OSGi中，接口是所謂的微服務(wù)的基礎(chǔ) 。通過在注冊表中發(fā)布服務(wù)，我們可以使客戶端無需知道哪個(gè)對象實(shí)現(xiàn)了給定的接口。換句話說，客戶端可以發(fā)現(xiàn)提供服務(wù)的對象的身份。服務(wù)注冊表成為我們訪問功能的入口。

這些接口被稱為微服務(wù)是有原因的：它們是構(gòu)成面向服務(wù)的體系結(jié)構(gòu) （SOA）的服務(wù)的微型版本。

將微服務(wù)直接擴(kuò)展到“ SOA服務(wù)”會導(dǎo)致RPC樣式的實(shí)現(xiàn)，例如使用SOAP。但是，我們早先已經(jīng)確定RPC不是調(diào)用遠(yuǎn)程代碼的最佳方法。

輸入REST。

RESTful服務(wù)

代表性狀態(tài)轉(zhuǎn)移（REST）是一種體系結(jié)構(gòu)樣式，將Web的優(yōu)點(diǎn)帶入了程序世界。

不能否認(rèn)Web的可伸縮性，因此這是一個(gè)有趣的角度。

與其解釋REST通常通過探索其體系結(jié)構(gòu)約束來完成，不如將其與微服務(wù)進(jìn)行比較。

設(shè)計(jì)良好的RESTful服務(wù)具有單個(gè)入口點(diǎn)，例如微服務(wù)注冊表。該入口點(diǎn)可以采用家庭資源的形式。

我們像訪問任何其他資源一樣訪問主頁資源：通過表示。表示形式是我們需要解釋的一系列字節(jié)。這種解釋的規(guī)則由媒體類型給出。

如今，大多數(shù)RESTful服務(wù)都基于JSON或XML表示。資源的媒體類型與對象的接口進(jìn)行比較。

一些接口包含使我們能夠訪問其他接口的方法。同樣，資源的表示形式可能包含指向其他資源的超鏈接。

基于代碼的服務(wù)與基于數(shù)據(jù)的服務(wù)

REST和SOAP之間的區(qū)別現(xiàn)在變得顯而易見。

在SOAP中，就像在微服務(wù)中一樣，該接口由方法組成。換句話說，它是基于代碼的。

另一方面，在REST中，接口由代碼和數(shù)據(jù)組成。我們已經(jīng)看過數(shù)據(jù)：媒體類型描述的表示形式。該代碼是統(tǒng)一接口，這意味著所有資源都相同（統(tǒng)一）。

實(shí)際上，統(tǒng)一接口由HTTP方法 GET，POST，PUT和DELETE組成。

由于統(tǒng)一接口對于所有資源都是固定的，因此任何RESTful服務(wù)中的真正汁液都不在代碼中，而在數(shù)據(jù)中：媒體類型。

正如有發(fā)展Java接口的規(guī)則一樣，也有發(fā)展媒體類型的規(guī)則，例如，基于XML的媒體類型。（由此得出的結(jié)論是，您不能對基于XML的媒體類型使用XML模式驗(yàn)證。）

統(tǒng)一資源標(biāo)識符

到目前為止，我還沒有提到統(tǒng)一資源標(biāo)識符（URI）。許多所謂的RESTful服務(wù)的文檔可能會讓您覺得它們很重要。

但是，由于URI標(biāo)識資源，因此它們在微服務(wù)中的等效項(xiàng)是實(shí)現(xiàn)接口的對象的標(biāo)識。

希望這表明客戶端不必關(guān)心URI。僅本地資源的URI很重要。

家庭資源的表示形式包含指向其他資源的鏈接。這些鏈接的含義由鏈接關(guān)系指示。

通過了解鏈接關(guān)系，客戶端可以決定要遵循的鏈接，并從表示形式中發(fā)現(xiàn)其URI。

服務(wù)版本

我們應(yīng)盡可能遵循不斷發(fā)展的媒體類型的規(guī)則，而不引入任何重大變化。

但是，有時(shí)這是不可避免的。然后，我們應(yīng)該創(chuàng)建該服務(wù)的新版本。

由于URI不是RESTful API的公共接口的一部分，因此它們不是中繼版本信息的正確工具。可以通過與微服務(wù)進(jìn)行比較來得出指示API主要（即不兼容）版本的正確方法。

每當(dāng)服務(wù)引入重大更改時(shí)，都應(yīng)更改其接口。在RESTful API中，這意味著更改媒體類型。然后，客戶端可以使用內(nèi)容協(xié)商來請求其理解的媒體類型。

你怎么看？

可以找到有關(guān)如何設(shè)計(jì)和記錄基于代碼的接口的文獻(xiàn)。

對于基于數(shù)據(jù)的接口（如媒體類型），情況并非如此。

隨著RESTful服務(wù)變得越來越流行，這是需要填補(bǔ)的空白。以后我會回到這個(gè)話題。

您如何設(shè)計(jì)服務(wù)？您如何記錄它們？

參考： REST 101對于開發(fā)人員，來自我們的JCG合作伙伴 Remon Sinnema，位于安全軟件開發(fā)博客上。

翻譯自: https://www.javacodegeeks.com/2013/09/rest-101-for-developers.html