我在 IT 行業有 2 年的時間，我喜歡閱讀很多東西，但是當我深入研究某些主題時，我會在某些文章、論壇或可互換使用的術語中看到很多矛盾。
我了解肥皂和休息之間的區別。當我們想在后端之間進行通信時，我們可以使用這兩種方法中的任何一種，每種方法都有其優點和缺點。
情況 ：
如果我有一個應用程式，它可以是單片的，也可以不是單片的，我有一個后端，我只會有一個使用它的前端。通常我們創建一個 Rest Api 以便我們的前端可以使用它。但是我們永遠不會考慮用 Soap 暴露我們的后端。（很多原因）
問題：
1 - 如果我說 Rest 可以嗎，除了可以讓我們在應用程式和應用程式之間（后端到后端）交換資訊之外，它在為我們的前端暴露服務時是否也有用？而 SOAP 只對服務器 - 服務器通信有用嗎？
2-最后，如果我只為前端公開一個后端，可以說我們公開一個 Web 服務，或者從概念上說它是前端的后端？
uj5u.com熱心網友回復：
問題 1：否 第一個問題是錯誤的假設。可以說，在 SOAP 中，XML 是唯一的通信方式，而在 Rest 中，可接受的方式是 JSON，而還有其他格式，如 XML、JSON、PDF、HTML 等。當然，XML 可以從服務器轉換回來轉換為在服務器上解密的 UI 語言和 XML 請求以獲取回應。因此，不能說 SOAP 僅用于服務器 - 服務器通信。2. 不，當您通常只公開后端供前端使用時，您通常可以說它是眾多前端客戶端請求的后端。但是 IMO，前端的后端是一個單一的 Web 應用程式，兩者都捆綁在 WAR 中。所以從這個意義上說，任何 UI 請求都可以從后端 Web 服務請求回應。希望我能夠澄清您對 Web 服務的理解。
uj5u.com熱心網友回復：
我看到在您的問題中實際上有 4 個嵌入式獨立主題。可能是因為它們總是結合使用，所以有時很難理解。
我先做一個簡短的回答：
- REST 和 SOAP 都可用于客戶端-服務器和服務器-服務器集成。但是選擇將取決于諸如您想要服務器端 UI 技術/客戶端 UI 技術還是單頁應用程式/門戶技術等問題。
- 如果您為單個前端公開單個后端，則它在技術上是 BFF，盡管術語 BFF 僅用于每種型別的前端應用程式都有單獨的后端的情況。例如，一種用于移動設備，一種用于網路，一種用于物聯網設備等。
長答案是澄清4個原則。讓我通過將主題分為以下四個標題來嘗試一下：
1.后端（業務層）與前端（BFF）的后端
- 在經典的三層架構（UI-Business Layer-Database）世界中，由業務和集成邏輯組成的中間層大多被稱為后端/業務層。
- 該層可以使用多種不同的選項（如 API（REST/SOAP）、RPC、Servlet 技術等）與 UI/前端分離。這種 3 層架構的局限性在于，它仍然與用戶型別緊密耦合和用例僅限于基于網路/瀏覽器。當您希望為 Web 和移動設備重用業務層時，這不是一個好的選擇，因為原則上要求移動應用程式是輕量級的。
- 這就是我們依靠以后端換前端（BFF）為救星的多層架構的地方。這只是一種基于消費者分離業務層的方法。
2. Monolith vs SOA vs Microservices（優化的 SOA）
- 在單體世界中，所有代碼組件（主要是 UI 和業務層）都以緊密耦合的方式存在。最簡單的示例是使用 Java 作為業務層的 Java Servlet Pages(JSP) 應用程式。這些通常是服務器端 UI 技術。
- 在面向服務的架構 (SOA) 中，用例圍繞著利用可重用的業務層功能（即服務）展開。這里必須處理 UI-Server、Inter-Service 和 Server-Server 集成場景。它嚴重依賴服務，這意味著它就像一個依賴應用程式的蜘蛛網。
- 微服務是 SOA 的擴展，但方法是保持資源而不是服務的焦點，以減少蜘蛛網的依賴性。因此，自給自足和獨立的服務集群是微服務架構的基礎。
3. SOAP 與 REST Web 服務
- SOAP 代表簡單物件訪問協議，業務層通常使用它來提供用戶定義的方法/服務來操作物件。例如，查看訪問圖書收藏的服務名稱
- 獲取一本書 getABook()
- 獲取整個圖書串列 listAllBooks()
- 按名稱查找書籍 searchABook(String name)
- 更新一本書的詳細資訊 updateABookDetails()
- 另一方面，REST 是表示狀態傳輸，它使用底層現有的 HTTP 方法將 Web 資源的狀態傳輸到客戶端。所以上述訪問圖書收藏的服務看起來像
- 獲取一本書 /book(HTTP GET)
- 獲取書籍/書籍的完整串列（HTTP GET）
- 按名稱查找一本書 /book?name={search}(HTTP GET)
- 更新一本書的詳細資訊 /book/{bookId}(HTTP PATCH/PUT)
4、如何正確選擇架構？
- 發現應用程式用戶組和用途的多樣性：這將有助于了解平臺（網路/移動/物聯網/等）、應用程式的性質和會話管理。
- 確定估計/所需的吞吐量：這將幫助您了解可伸縮性要求。
- 維護應用程式的頻率和人員：這將有助于衡量應用程式和技術的復雜性、部署周期、部署策略、對停機時間的需求等。
總之，始終遵循 KISS 的神圣規則：保持簡單，愚蠢。
uj5u.com熱心網友回復：
1.)
Web 應用程式用于 H2M 通信，Web 服務用于通過 Web 進行 M2M 通信。服務的介面更加標準化，更加結構化，機器可以輕松使用它并決議訊息。
我認為您的服務使用者在哪里并不重要，它可以在瀏覽器中運行，也可以在服務器上運行。只要它可以在相對安全的通道上與服務通信就可以了。
您通常設計一個服務以將其與多個不同的消費者分離，因此您不必處理消費者實作。當您有潛在的未知消費者通常由您甚至不知道或想知道的第 3 方程式員撰寫時，這通常是有意義的。您對服務或至少對訊息進行版本控制以與舊消費者保持兼容。
如果你只開發了一個消費者，那么維護一個具有準標準介面的服務可能會花費太多額外的精力。當你改變服務的介面時，你可以很容易地改變消費者的代碼，所以考慮介面設計、標準化、向后兼容等沒有多大意義。盡管您仍然可以在沒有太多設計的情況下使用 REST 或 SOAP ad hoc。在這種情況下，我認為沒有超媒體的 RESTish CRUD API 是一個更好的選擇。
2.)
我認為兩者都很好，我會在你的場景中說后端。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/484449.html