rest开发_REST 101开发人员专用
rest開(kāi)發(fā)
本地代碼執(zhí)行
諸如C之類(lèi)的高級(jí)語(yǔ)言中的函數(shù)將被匯編為Assembly中的過(guò)程 。 它們?cè)黾恿艘粋€(gè)間接級(jí)別，使我們不必考慮內(nèi)存地址。
諸如Java之類(lèi)的面向?qū)ο笳Z(yǔ)言中的方法和多態(tài)性增加了另一種間接性 ，使我們不必考慮一組相似功能的特定變體。
盡管有這些間接性，方法基本上仍然是過(guò)程調(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ī)甚至可能沒(méi)有相同的操作系統(tǒng)，程序可以通過(guò)該操作系統(tǒng)訪問(wèn)內(nèi)存。
因此，嘗試盡可能隱藏這種差異的遠(yuǎn)程代碼執(zhí)行機(jī)制（例如RMI或SOAP ）在很大程度上失敗并不奇怪。 這種技術(shù)采用了所謂的遠(yuǎn)程過(guò)程調(diào)用 （RPC）。
我們必須區(qū)分本地過(guò)程調(diào)用和遠(yuǎn)程過(guò)程調(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é)作，需要某種形式的協(xié)調(diào)。 這就是我們?yōu)轳詈细冻龅拇鷥r(jià)。
通過(guò)接口協(xié)調(diào)變更
我們還可以在單??個(gè)過(guò)程中看到此問(wèn)題，例如，當(dāng)代碼部署在不同的jar文件中時(shí)。 如果升級(jí)代碼所依賴(lài)的第三方j(luò)ar文件，則可能需要更改代碼以使一切正常運(yùn)行。
這種協(xié)調(diào)令人討厭。 如果我們只需部署該jar的最新安全補(bǔ)丁程序而不必?fù)?dān)心破壞我們的代碼，那就更好了。 幸運(yùn)的是，如果我們謹(jǐn)慎的話(huà)，我們可以。
Java之類(lèi)的語(yǔ)言接口將代碼的公共部分和私有部分分開(kāi)。
客戶(hù)所依賴(lài)的是公共部分，因此您必須以謹(jǐn)慎的方式開(kāi)發(fā)接口，以避免破壞客戶(hù)。
相反，私有部分可以隨意更改。
從界面到服務(wù)
在OSGi中 ，接口是所謂的微服務(wù)的基礎(chǔ) 。 通過(guò)在注冊(cè)表中發(fā)布服務(wù)，我們可以使客戶(hù)端無(wú)需知道哪個(gè)對(duì)象實(shí)現(xiàn)了給定的接口。 換句話(huà)說(shuō)，客戶(hù)端可以發(fā)現(xiàn)提供服務(wù)的對(duì)象的身份。 服務(wù)注冊(cè)表成為我們?cè)L問(wèn)功能的入口。
這些接口被稱(chēng)為微服務(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通常通過(guò)探索其體系結(jié)構(gòu)約束來(lái)完成，不如將其與微服務(wù)進(jìn)行比較。
設(shè)計(jì)良好的RESTful服務(wù)具有單個(gè)入口點(diǎn)，例如微服務(wù)注冊(cè)表。 該入口點(diǎn)可以采用家庭資源的形式。
我們像訪問(wèn)任何其他資源一樣訪問(wèn)主頁(yè)資源：通過(guò)表示。 表示形式是我們需要解釋的一系列字節(jié)。 這種解釋的規(guī)則由媒體類(lèi)型給出。
如今，大多數(shù)RESTful服務(wù)都基于JSON或XML表示。 資源的媒體類(lèi)型與對(duì)象的接口進(jìn)行比較。
一些接口包含使我們能夠訪問(wèn)其他接口的方法。 同樣，資源的表示形式可能包含指向其他資源的超鏈接 。
基于代碼的服務(wù)與基于數(shù)據(jù)的服務(wù)
REST和SOAP之間的區(qū)別現(xiàn)在變得顯而易見(jiàn)。
在SOAP中，就像在微服務(wù)中一樣，該接口由方法組成。 換句話(huà)說(shuō)，它是基于代碼的。
另一方面，在REST中，接口由代碼和數(shù)據(jù)組成。 我們已經(jīng)看過(guò)數(shù)據(jù)：媒體類(lèi)型描述的表示形式。 該代碼是統(tǒng)一接口 ，這意味著所有資源都相同（統(tǒng)一）。
實(shí)際上，統(tǒng)一接口由HTTP方法 GET，POST，PUT和DELETE組成。
由于統(tǒng)一接口對(duì)于所有資源都是固定的， 因此任何RESTful服務(wù)中的真正汁液都不在代碼中，而在數(shù)據(jù)中：媒體類(lèi)型 。
正如有發(fā)展Java接口的規(guī)則一樣，也有發(fā)展媒體類(lèi)型的規(guī)則，例如， 基于XML的媒體類(lèi)型 。 （由此得出的結(jié)論是， 您不能對(duì)基于XML的媒體類(lèi)型使用XML模式驗(yàn)證 。）
統(tǒng)一資源標(biāo)識(shí)符
到目前為止，我還沒(méi)有提到統(tǒng)一資源標(biāo)識(shí)符 （URI）。 許多所謂的RESTful服務(wù)的文檔可能會(huì)讓您覺(jué)得它們很重要。
但是，由于URI標(biāo)識(shí)資源，因此它們?cè)谖⒎?wù)中的等效項(xiàng)是實(shí)現(xiàn)接口的對(duì)象的標(biāo)識(shí)。
希望這表明客戶(hù)端不必關(guān)心URI。 僅本地資源的URI很重要。
家庭資源的表示形式包含指向其他資源的鏈接。 這些鏈接的含義由鏈接關(guān)系指示。
通過(guò)了解鏈接關(guān)系，客戶(hù)端可以決定要遵循的鏈接，并從表示形式中發(fā)現(xiàn)其URI。
服務(wù)版本
我們應(yīng)盡可能遵循不斷發(fā)展的媒體類(lèi)型的規(guī)則，而不引入任何重大變化。
但是，有時(shí)這是不可避免的。 然后，我們應(yīng)該創(chuàng)建該服務(wù)的新版本。
由于URI不是RESTful API的公共接口的一部分，因此它們不是中繼版本信息的正確工具。 可以通過(guò)與微服務(wù)進(jìn)行比較來(lái)得出指示API主要（即不兼容）版本的正確方法。
每當(dāng)服務(wù)引入重大更改時(shí)，都應(yīng)更改其接口。 在RESTful API中，這意味著更改媒體類(lèi)型。 然后，客戶(hù)端可以使用內(nèi)容協(xié)商來(lái)請(qǐng)求其理解的媒體類(lèi)型。
你怎么看？
可以找到有關(guān)如何設(shè)計(jì)和記錄基于代碼的接口的文獻(xiàn)。
對(duì)于基于數(shù)據(jù)的接口（如媒體類(lèi)型），情況并非如此。
隨著RESTful服務(wù)變得越來(lái)越流行，這是需要填補(bǔ)的空白。 以后我會(huì)回到這個(gè)話(huà)題。
您如何設(shè)計(jì)服務(wù)？ 您如何記錄它們？
翻譯自: https://www.javacodegeeks.com/2013/09/rest-101-for-developers.html
rest開(kāi)發(fā)
總結(jié)
以上是生活随笔為你收集整理的rest开发_REST 101开发人员专用的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Linux网络命令（linux 网络 命
- 下一篇： JVM体系结构：JVM中的执行引擎