rest開發(fā)

本地代碼執(zhí)行

諸如C之類的高級(jí)語言中的函數(shù)將被匯編為Assembly中的過程 。 它們?cè)黾恿艘粋€(gè)間接級(jí)別，使我們不必考慮內(nèi)存地址。

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

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

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

這與將執(zhí)行切換到另一個(gè)進(jìn)程或另一臺(tái)計(jì)算機(jī)根本不同。 特別是后者非常不同，因?yàn)榱硪慌_(tái)計(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的速度慢得多。

對(duì)于大多數(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)用的代碼位于另一臺(tái)計(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í)代碼所依賴的第三方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ǔ) 。 通過在注冊(cè)表中發(fā)布服務(wù)，我們可以使客戶端無需知道哪個(gè)對(duì)象實(shí)現(xiàn)了給定的接口。 換句話說，客戶端可以發(fā)現(xiàn)提供服務(wù)的對(duì)象的身份。 服務(wù)注冊(cè)表成為我們?cè)L問功能的入口。

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

將微服務(wù)直接擴(kuò)展到“ SOA服務(wù)”會(huì)導(dǎo)致RPC樣式的實(shí)現(xiàn)，例如使用SOAP。 但是，我們?cè)缦纫呀?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ù)注冊(cè)表。 該入口點(diǎn)可以采用家庭資源的形式。

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

如今，大多數(shù)RESTful服務(wù)都基于JSON或XML表示。 資源的媒體類型與對(duì)象的接口進(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)一接口對(duì)于所有資源都是固定的， 因此任何RESTful服務(wù)中的真正汁液都不在代碼中，而在數(shù)據(jù)中：媒體類型 。

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

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

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

但是，由于URI標(biāo)識(shí)資源，因此它們?cè)谖⒎?wù)中的等效項(xiàng)是實(shí)現(xiàn)接口的對(duì)象的標(biāo)識(shí)。

希望這表明客戶端不必關(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é)商來請(qǐng)求其理解的媒體類型。

你怎么看？

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

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

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

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

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

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

rest開發(fā)

總結(jié)

以上是生活随笔為你收集整理的rest开发_REST 101开发人员专用的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。