我在IT行业工作了两年，我喜欢读很多书，但当我深入研究某些主题时，我发现一些文章、论坛或可互换的术语中有很多矛盾。
我理解肥皂和休息的区别。当我们想在后台之间进行通信时，我们可以使用这两种方法中的任何一种，每种方法都有其优缺点。
情况：
如果我有一个应用程序，它可以是单片的，也可以不是单片的，我有后端，我只会有一个前端来消耗它。通常我们会创建一个Rest Api，这样我们的前端就可以消耗它。但我们永远不会考虑用Soap暴露我们的后端。(原因很多)
问题：
1-如果我说Rest，除了允许我们在应用程序和应用程序之间交换信息(后端到后端)之外，它在为我们的前端公开服务时也有用吗？SOAP只对服务器-服务器通信有用吗？
2-最后，如果我只为前端公开后端，那么可以说我们公开了一个web服务，或者从概念上说它是前端的后端？
问题1：不，第一个问题是错误的假设。我们可以说，在SOAP中，XML是唯一的通信方式，而在Rest中，可接受的方式是JSON，而还有其他格式，如XML、JSON、PDF、HTML等。当然，XML可以从服务器转换回UI语言，并在服务器处解密XML请求以获得响应。所以，不能说SOAP只用于服务器-服务器通信。2.不，当您通常只公开后端供前端使用时，您通常可以说它是许多前端客户端请求的后端。但是IMO，前端的后端是一个单一的网络应用程序，两者都捆绑在WAR中。因此，从这个意义上讲，任何UI请求都可以从后端web服务请求响应。希望我能澄清你对网络服务的理解。
我看到在你的问题中实际上有4个嵌入的独立主题。可能是因为它们总是结合使用，所以有时很难理解。
我将首先给出一个简短的答案：
- REST和SOAP都可以用于客户端服务器和服务器服务器集成。但选择将取决于以下问题，如您希望服务器端UI技术/客户端UI技术在哪里或是单页应用程序/门户技术，等等
- 如果您为单个前端公开单个后端，那么从技术上讲，它就是BFF，尽管术语BFF仅用于每种类型的前端应用程序都有单独后端的情况。例如一个用于移动设备，一个用于网络，一个适用于物联网设备等
长篇大论的答案是澄清这4条原则。让我尝试一下，将主题分为以下四个标题：
1.后端(业务层)与前端的后端(BFF)
- 在经典的三层体系结构(UI业务层数据库)世界中，由业务和集成逻辑组成的中间层通常被称为后端/业务层
- 该层可以使用多种不同的选项(如API(REST/SOAP)、RPC、Servlet技术等)与UI/Frontend分离。这种三层架构的局限性在于，它仍然与用户类型紧密耦合，并且用例仅限于基于web/浏览器。当您想为web和移动应用程序重用业务层时，这不是一个好的选择，因为原则上移动应用程序需要轻量级
- 这就是我们依靠多层体系结构的地方，前端后端(BFF)是救世主。这只是一种基于消费者来隔离业务层的方法
2.Monolith与SOA与微服务(优化的SOA)
- 在一个单一的世界中，所有的代码组件(主要是UI和业务层)都是紧密耦合的。最简单的例子是使用Java作为业务层的Java Servlet Pages(JSP)应用程序。这些通常是服务器端UI技术
- 在面向服务的体系结构(SOA)中，用例围绕着利用可重用的业务层功能(即服务)展开。在这里，必须处理UI服务器、服务间和服务器服务器集成场景。它严重依赖于服务，这意味着它就像一个依赖应用程序的蜘蛛网
- 微服务是SOA的扩展，但方法是集中资源而不是服务，以减少对蜘蛛网的依赖。因此，自给自足和独立的服务集群是微服务体系结构的基础
3.SOAP与REST Web服务
- SOAP代表简单对象访问协议，通常由业务层使用，以提供用户定义的方法/服务来操作对象。例如，查看用于访问图书收藏的服务的名称
- 获取书籍getABook()
- 获取完整的图书列表AllBooks()
- 按名称searchABook(字符串名称)查找书籍
- 更新书籍的详细信息updateABookDetails()
- 另一方面，REST是代表性的状态传输，使用底层现有HTTP方法将web资源的状态传输到客户端。因此，上述访问图书收藏的服务看起来像
- 获取图书(HTTP get)
- 获取图书的完整列表(HTTP Get)
- 按名字/书找书吗？name＝｛search｝(HTTP GET)
- 更新书籍的详细信息/book/｛bookId｝(HTTP PATCH/PUT)
4.如何正确选择架构
- 发现应用程序用户组和用途的多样性：这将有助于了解平台(web/mobile/IoT/etc)、应用程序的性质和会话管理
- 确定估计的/所需的吞吐量：这将帮助您了解可扩展性要求
- 维护应用程序的频率和人员：这将有助于衡量应用程序和技术的复杂性、部署周期、部署策略、停机需求等
总之，永远遵循KISS的神圣规则：保持简单，愚蠢
1.)
网络应用程序用于H2M通信，网络服务用于通过网络进行M2M通信。服务的接口更加标准化、结构化，因此机器可以轻松地使用它并解析消息。
我认为你的服务消费者在哪里并不重要，它可以在浏览器中运行，也可以在服务器上运行。只要它能在相对安全的信道上与服务通信，它就没问题
设计服务通常是为了将其与多个不同的使用者解耦，因此不必处理使用者实现。当你有潜在的未知消费者时，这通常是有道理的，通常是由你甚至不认识或不想知道的第三方程序员编程的。您对服务或至少消息进行了版本调整，以与旧消费者保持兼容。
如果您只开发了一个使用者，那么维护一个具有准标准接口的服务可能会付出太多额外的努力。当你更改服务的接口时，你可以很容易地更改消费者的代码，所以考虑接口设计、标准化、向后兼容性等没有多大意义。尽管您仍然可以在没有太多设计的情况下使用REST或SOAP。在这种情况下，拥有一个没有超媒体的RESTish CRUD API是一个更好的选择。
2.)
我认为两者都很好，我想在你的场景中说后端。