如今，當我們構(gòu)建Web應(yīng)用程序時，將所有功能公開為RESTful API，然后自己使用它是一種最佳實踐。 這通常與使用繁重的javascript的豐富前端配合使用，例如Angular / Ember / Backbone / React。

但是沉重的前端似乎不是一個很好的默認值–需要概念上沉重的javascript框架開銷的應(yīng)用程序?qū)嶋H上并不是絕大多數(shù)。 網(wǎng)絡(luò)雖然復(fù)雜得多，但仍然不僅僅是單頁應(yīng)用程序。 更不用說，如果您正在編寫靜態(tài)類型的后端，則可能需要一個專用的javascript團隊（不一定是個好主意，尤其是在小型公司/初創(chuàng)企業(yè)中），或者您必須在其中編寫……不太令人愉快語言。 老實說，我的瀏覽器到處都在使用所有不必要JavaScript，但這是一個獨立的故事。

讓自己使用自己的RESTful API的另一種選擇是擁有一個“ Web”模塊，該模塊調(diào)用您的“后端”模塊。 這可能是一個好主意，尤其是在您擁有不同專業(yè)的不同團隊的情況下，但是為了分離而引入如此多的通信開銷似乎至少應(yīng)該在操作前三思。 更不用說現(xiàn)實中的發(fā)布周期通常是捆綁在一起的，因為您需要付出額外的努力才能使“ Web”和“后端”保持適當?shù)耐?#xff08;“ Web”不請求“后端”尚未提供的服務(wù)，或者“后端”未提供“網(wǎng)絡(luò)”不期望的修改后的響應(yīng)模型）。

正如我對整體的辯護一樣 ，我顯然傾向于整體應(yīng)用。 我不會重復(fù)另一篇文章，但是我的想法是，即使應(yīng)用程序在單個運行時（例如JVM）中運行，也可以是模塊化的。 有了您的“ Web”軟件包，有了您的“服務(wù)”軟件包，它們可以獨立開發(fā)，甚至可以作為單獨的（子）項目編譯成一個可部署的工件。

因此，如果您想要一個傳統(tǒng)的Web應(yīng)用程序-請求/響應(yīng)，一點點的ajax，但又沒有繁瑣的javascript幻想，也沒有架構(gòu)開銷，并且仍然想將服務(wù)公開為RESTful API，該怎么辦？

您的Web層-控制器，使用來自表單提交的請求參數(shù)并使用模板引擎呈現(xiàn)響應(yīng)-通常與您的服務(wù)層通信。 因此，對于您的Web層，服務(wù)層只是一個API。 它通過JVM內(nèi)部的方法調(diào)用來使用它。 但這不是使用服務(wù)層的唯一方法。 諸如Spring-MVC，Jersey等框架允許注釋任何方法并將其作為RESTful服務(wù)公開。 通常，服務(wù)層不公開為Web組件，但可以公開。 因此–您通過方法調(diào)用使用了服務(wù)層API，其他所有人都通過HTTP使用了它。 相同的定義，相同的輸出，相同的安全性。 而且，您不需要單獨的傳遞層即可擁有RESTful API。

從理論上講，這聽起來不錯。 在實踐中，將方法變成端點的注釋可能會帶來問題-序列化/反序列化是否正常工作，標題是否正確處理，身份驗證是否正確。 而且，如果僅在單個JVM中使用方法，您將不會知道這些方法不起作用。 是的，您會知道它們在業(yè)務(wù)邏輯方面可以正常工作，但是啟用RESTful的部分可能有所不同。

這就是為什么您需要全面接受驗收測試的原因。 諸如黃瓜/ JBehave之類的東西可以測試所有暴露的端點。 這樣，您將確保RESTful方面和業(yè)務(wù)邏輯均正常運行。 無論如何，實際上實際上是應(yīng)該存在的東西，因此沒有開銷。

另一個問題是您可能希望將API與主應(yīng)用程序分開部署。 https://yoursite.com和https://api.yoursite.com。 您可能只希望在一個集群中運行API，而在另一個集群中運行您的應(yīng)用程序。 沒問題–您可以使用配置開關(guān)和應(yīng)用程序簡單地禁用“ Web”部分，并多次部署相同的工件。

我不得不承認我還沒有嘗試過這種方法，但是它看起來像是一種簡單的方法，仍然可以正確覆蓋所有用例。

翻譯自: https://www.javacodegeeks.com/2016/09/traditional-web-apps-restful-apis.html

總結(jié)

以上是生活随笔為你收集整理的传统的Web应用程序和RESTful API的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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