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

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

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

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

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

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

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

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

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

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

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

總結

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

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