本地代碼執行

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

諸如Java之類的面向對象語言中的方法和多態性增加了另一種間接性 ，使我們不必考慮一組相似功能的特定變體。

盡管有這些間接方式，但方法基本上仍然是過程調用，告訴計算機將執行流從一個內存位置切換到另一個內存位置。 所有這些都是在同一臺計算機上運行的同一進程中發生的。

遠程執行代碼

這與將執行切換到另一個進程或另一臺計算機根本不同。 特別是后者非常不同，因為另一臺計算機甚至可能沒有相同的操作系統，程序可以通過該操作系統訪問內存。

因此，嘗試盡可能隱藏這種差異的遠程代碼執行機制（例如RMI或SOAP ）在很大程度上失敗并不奇怪。 這種技術采用了所謂的遠程過程調用 （RPC）。

我們必須區分本地過程調用和遠程過程調用的原因之一是RPC的速度慢得多。

對于大多數實際應用程序，這將改變您進行的調用的性質：您將希望進行較少的遠程調用，而這些調用的粒度更粗。

另一個原因是本質上組織性比技術性強。

當您調用的代碼位于另一臺計算機上的另一個進程中時，該另一個進程很可能是由其他人編寫和部署的。 為了使這兩段代碼能夠很好地協作，需要某種形式的協調。 這就是我們為耦合付出的代價。

通過界面協調變更

我們還可以在單??個過程中看到此問題，例如，當代碼部署在不同的jar文件中時。 如果升級代碼所依賴的第三方jar文件，則可能需要更改代碼以使一切正常。

這種協調令人討厭。 如果我們只需部署該jar的最新安全補丁程序而不必擔心破壞我們的代碼，那就更好了。 幸運的是，如果我們謹慎的話，我們可以。

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

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

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

從界面到服務

在OSGi中 ，接口是所謂的微服務的基礎 。 通過在注冊表中發布服務，我們可以使客戶端無需知道哪個對象實現了給定的接口。 換句話說，客戶端可以發現提供服務的對象的身份。 服務注冊表成為我們訪問功能的入口。

這些接口被稱為微服務是有原因的：它們是構成面向服務的體系結構 （SOA）的服務的微型版本。

將微服務直接擴展到“ SOA服務”會導致RPC樣式的實現，例如使用SOAP。 但是，我們早先已經確定RPC不是調用遠程代碼的最佳方法。

輸入REST。

RESTful服務

代表性狀態轉移 （REST）是一種體系結構樣式，將Web的優點帶入了程序世界。

不能否認Web的可伸縮性，因此這是一個有趣的角度。

與其解釋REST通常通過探索其體系結構約束來完成，不如將其與微服務進行比較。

設計良好的RESTful服務具有單個入口點，例如微服務注冊表。 該入口點可以采用家庭資源的形式。

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

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

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

基于代碼的服務與基于數據的服務

REST和SOAP之間的區別現在變得顯而易見。

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

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

實際上，統一接口由HTTP方法 GET，POST，PUT和DELETE組成。

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

正如有發展Java接口的規則一樣，也有發展媒體類型的規則，例如， 基于XML的媒體類型 。 （由此得出結論， 您不能對基于XML的媒體類型使用XML模式驗證 。）

統一資源標識符

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

但是，由于URI標識資源，因此它們在微服務中的等效項是實現接口的對象的標識。

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

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

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

服務版本

我們應盡可能遵循不斷發展的媒體類型的規則，而不引入任何重大變化。

但是，有時這是不可避免的。 然后，我們應該創建該服務的新版本。

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

每當服務引入重大更改時，都應更改其接口。 在RESTful API中，這意味著更改媒體類型。 然后，客戶端可以使用內容協商來請求其理解的媒體類型。

你怎么看？

可以輕松獲得有關如何設計和記錄基于代碼的接口的文獻。

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

隨著RESTful服務變得越來越流行，這是需要填補的空白。 以后我會回到這個話題。

您如何設計服務？ 您如何記錄它們？

參考： REST 101對于我們的JCG合作伙伴 Remon Sinnema的開發人員 ，請訪問安全軟件開發博客。

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

總結

以上是生活随笔為你收集整理的REST 101开发人员专用的全部內容，希望文章能夠幫你解決所遇到的問題。

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