要回答这个问题，了解分布式应用程序的架构从简单的分层架构到基于对象和服务的架构，再到基于资源的架构，现在我们甚至有了基于事件的架构，这是很有用的。大多数大型系统使用风格的组合。

第一个分布式应用程序具有分层的体系结构。我想这里的每个人都知道什么是层。这些结构被整齐地组织起来，并且可以是堆栈或循环结构。努力维护单向数据流。

基于对象的体系结构从分层体系结构发展而来，遵循一个更宽松的模型。在这里，每个组件都是一个对象(通常称为分布式对象)。对象之间使用类似于远程过程调用的机制进行交互——当客户端绑定到分布式对象时，它将对象接口的实现加载到其地址空间中。RPC存根可以封送请求并接收响应。同样，服务器上的对象接口是一个RPC样式的存根。这些基于对象的系统的结构组织得不是很整齐，它看起来更像一个对象图。

分布式对象的接口隐藏了它的实现。与分层组件一样，如果接口定义得很清楚，内部实现就可以改变——甚至完全替换。
基于对象的体系结构为封装服务提供了基础。服务是由自包含的实体提供的，尽管在内部它可以使用其他服务。逐渐地，基于对象的体系结构演变为面向服务的体系结构。

使用SOA，分布式应用程序由服务组成。这些服务可以跨管理域提供——它们可以在web上可用(即由云提供商提供的存储服务)。

随着web服务的流行，越来越多的应用程序开始使用它们，服务组合(将服务组合成新的服务)变得更加重要。SOA的一个问题是，集成不同的服务可能会变得极其复杂。


虽然SOAP是一种协议，但它的使用意味着面向服务的体系结构。SOAP试图为服务提供一种标准，通过这种标准，服务可以组合并易于集成。

基于资源的体系结构是解决SOA集成问题的不同方法。其思想是将分布式系统视为由组件单独管理的巨大资源集合。 这导致了RESTful体系结构的开发。RESTful服务的一个特征是无状态执行。这与由服务器维护状态的SOA不同。

那么……由面向服务的体系结构(包括使用SOAP的体系结构)提供的特定于服务的接口与基于资源的体系结构(如REST)相比如何?



虽然REST很简单，但它并没有为复杂的通信方案提供简单的接口。例如，如果要求使用事务REST是不合适的，那么最好将复杂状态封装在服务器上，而不是让客户端管理事务。但是在许多场景中，RESTful体系结构中资源的正交使用极大地简化了服务的集成，否则就意味着服务接口的激增。另一个权衡是基于资源的架构给客户端增加了更多的复杂性，并增加了网络上的流量，而基于服务的架构增加了服务器的复杂性，并占用了它的内存和CPU资源。

有些人还提到了常见的HTTP服务或其他不满足RESTful体系结构或SOAP需求的服务。这些也可以分为基于服务的或基于资源的。它们的优点是实现起来更简单。只有当您知道您的服务永远不需要跨管理域集成时，才会使用这种方法，因为这种方法不会试图修复出现的集成问题。

这些类型的基于http的服务，特别是伪rest式服务仍然是最常见的类型。实现SOAP是复杂的，只有当你真的需要它时才应该使用它——例如，你需要一个跨域容易集成的服务，并且你希望它有一个服务接口。在某些情况下仍然需要这样做。真正的rest式服务也很难实现，尽管没有SOAP那么难。

具象状态传输 对象的代表性状态传输是REST，即我们不发送对象，我们发送对象的状态。 REST是一种架构风格。它没有像SOAP那样定义那么多标准。REST用于公开公共api(例如:Facebook API，谷歌Maps API)通过互联网处理数据的CRUD操作。REST的重点是通过单一一致的接口访问命名资源。

简单对象访问协议 SOAP带来了自己的协议，并专注于将应用程序逻辑(而不是数据)片段作为服务公开。SOAP公开操作。SOAP关注于访问命名操作，每个操作实现一些业务逻辑。虽然SOAP通常被称为web服务，但这是用词不当。SOAP与Web几乎没有任何关系。REST提供了基于uri和HTTP的真正Web服务。

为什么休息?

由于REST使用标准的HTTP，它在任何方面都要简单得多。 REST更容易实现，需要的带宽和资源更少。 REST允许许多不同的数据格式，而SOAP只允许XML。 REST由于对JSON的支持，可以更好地支持浏览器客户端。 REST具有更好的性能和可伸缩性。REST读取可以被缓存，基于SOAP的读取不能被缓存。 如果安全不是主要问题，而我们的资源有限。或者我们想要创建一个其他开发人员可以轻易公开使用的API，那么我们应该选择REST。 如果我们需要无状态的CRUD操作，那么就使用REST。 REST通常用于社交媒体、网络聊天、移动服务和谷歌地图等公共api。 RESTful服务为相同的资源返回各种MediaTypes，这取决于请求头参数“Accept”，如application/xml或application/json for POST和/user/1234。json或GET /user/1234.xml。 REST服务应该由客户端应用程序调用，而不是由最终用户直接调用。 REST中的ST来自于状态传输。您可以四处传输状态，而不是让服务器存储它，这使得REST服务具有可伸缩性。

为什么肥皂?

SOAP不是很容易实现，需要更多的带宽和资源。 与REST相比，SOAP消息请求处理速度较慢，并且不使用web缓存机制。 WS-Security:虽然SOAP支持SSL(就像REST一样)，但它也支持添加了一些企业安全特性的WS-Security。 WS-AtomicTransaction:需要服务上的ACID事务，您将需要SOAP。 WS-ReliableMessaging:如果您的应用程序需要异步处理和有保证的可靠性和安全性级别。Rest没有标准的消息传递系统，并期望客户端通过重试来处理通信失败。 如果安全性是一个主要问题，并且资源不受限制，那么我们应该使用SOAP web服务。例如，如果我们正在为支付网关、金融和电信相关的工作创建web服务，那么我们应该使用SOAP，因为这里需要高安全性。

source1 source2

在众多答案中已经涉及的许多问题中，我将强调SOAP允许定义契约、WSDL(定义所支持的操作)、复杂类型等。 SOAP面向操作，而REST面向资源。 就我个人而言，对于企业内部应用程序之间的复杂接口，我会选择SOAP，而对于与外部世界的公共的、更简单的、无状态的接口，我会选择REST。

火休息

RESTful API是最著名的API类型。REST代表具象状态传输。

REST api是遵循标准化原则、属性和约束的api。

您可以使用HTTP谓词访问REST API中的资源。

REST api运行在一个简单的请求/响应系统上。您可以使用以下HTTP方法发送请求:

得到 帖子 把 补丁 删除 跟踪 选项 连接 头

下面是最常见的HTTP动词

GET(读取现有数据) POST(创建一个新的响应或数据) PATCH(更新数据) DELETE(删除数据)

客户机可以使用后跟端点的HTTP谓词发出请求。

端点(或路由)是您请求的URL。路径决定了您请求的资源。

当您向端点发送请求时，它将响应相关数据，这些数据通常格式化为JSON、XML、纯文本、图像、HTML等。

REST api还可以设计为许多返回不同类型数据的不同端点。使用REST API访问多个端点需要各种API调用。

一个实际的RESTful API遵循以下五个约束:

客户机-服务器体系结构 客户端向服务器请求数据，不需要第三方解释。 无国籍 无状态意味着每个HTTP请求都在完全隔离的情况下发生。每个请求都包含服务该请求所需的信息。服务器从不依赖以前请求的信息。没有国家。 缓存能力 响应可以显式或隐式地定义为可缓存或不可缓存，以提高可伸缩性和性能。例如，启用GET请求的缓存可以改善资源数据请求的响应时间。 分层 API体系结构的不同层应该协同工作，创建易于更新或调整的可伸缩系统。 统一的接口 客户端和服务器之间的通信必须使用独立于两者的标准化语言进行。这提高了可伸缩性和灵活性。

REST api非常适合需要它的项目

灵活的 可伸缩的 快

SOAP火

SOAP是一种必要的协议，它帮助引入api的广泛使用。

SOAP是简单对象访问协议的首字母缩写。

SOAP是一种标准化协议，它依赖于XML来发出请求和接收响应。

尽管SOAP是基于XML的，SOAP协议仍然被广泛使用。

SOAP API将数据作为服务提供，通常在执行涉及多个API调用或应用程序的事务时使用，其中安全性是主要考虑因素。

SOAP最初是在1998年为Microsoft开发的，它提供了一种标准机制，用于集成internet上的服务，而不考虑操作系统、对象模型或编程语言。

SOAP中的“S”代表Simple(简单)，这是有原因的——SOAP可以以更低的复杂性使用，因为它在应用程序层对事务、安全性和其他功能的编码要求更少。

SOAP有三个主要特征:

SOAP API的可扩展性 SOAP允许扩展引入更健壮的特性，如Windows服务器安全性、寻址等等。 SOAP API的中立性 SOAP能够在广泛的协议上操作，如UDP、JMS、SMTP、TCP和HTTP。可以操作。 SOAP API的独立性 SOAP API响应完全基于XML。因此SOAP api是独立于平台和语言的。

开发人员继续争论使用SOAP和REST的利弊。最适合你的项目的是符合你的需求的。

SOAP api仍然是优先考虑安全性的公司实体和政府组织的首选，尽管REST在很大程度上主导了web应用程序。 SOAP比REST更安全，因为它使用WS-Security与安全套接字层一起进行传输 SOAP还具有更出色的事务可靠性，这是SOAP在历史上一直受到银行业和其他大型实体青睐的另一个原因。

要回答这个问题，了解分布式应用程序的架构从简单的分层架构到基于对象和服务的架构，再到基于资源的架构，现在我们甚至有了基于事件的架构，这是很有用的。大多数大型系统使用风格的组合。

第一个分布式应用程序具有分层的体系结构。我想这里的每个人都知道什么是层。这些结构被整齐地组织起来，并且可以是堆栈或循环结构。努力维护单向数据流。

基于对象的体系结构从分层体系结构发展而来，遵循一个更宽松的模型。在这里，每个组件都是一个对象(通常称为分布式对象)。对象之间使用类似于远程过程调用的机制进行交互——当客户端绑定到分布式对象时，它将对象接口的实现加载到其地址空间中。RPC存根可以封送请求并接收响应。同样，服务器上的对象接口是一个RPC样式的存根。这些基于对象的系统的结构组织得不是很整齐，它看起来更像一个对象图。

分布式对象的接口隐藏了它的实现。与分层组件一样，如果接口定义得很清楚，内部实现就可以改变——甚至完全替换。
基于对象的体系结构为封装服务提供了基础。服务是由自包含的实体提供的，尽管在内部它可以使用其他服务。逐渐地，基于对象的体系结构演变为面向服务的体系结构。

使用SOA，分布式应用程序由服务组成。这些服务可以跨管理域提供——它们可以在web上可用(即由云提供商提供的存储服务)。

随着web服务的流行，越来越多的应用程序开始使用它们，服务组合(将服务组合成新的服务)变得更加重要。SOA的一个问题是，集成不同的服务可能会变得极其复杂。


虽然SOAP是一种协议，但它的使用意味着面向服务的体系结构。SOAP试图为服务提供一种标准，通过这种标准，服务可以组合并易于集成。

基于资源的体系结构是解决SOA集成问题的不同方法。其思想是将分布式系统视为由组件单独管理的巨大资源集合。 这导致了RESTful体系结构的开发。RESTful服务的一个特征是无状态执行。这与由服务器维护状态的SOA不同。

那么……由面向服务的体系结构(包括使用SOAP的体系结构)提供的特定于服务的接口与基于资源的体系结构(如REST)相比如何?



虽然REST很简单，但它并没有为复杂的通信方案提供简单的接口。例如，如果要求使用事务REST是不合适的，那么最好将复杂状态封装在服务器上，而不是让客户端管理事务。但是在许多场景中，RESTful体系结构中资源的正交使用极大地简化了服务的集成，否则就意味着服务接口的激增。另一个权衡是基于资源的架构给客户端增加了更多的复杂性，并增加了网络上的流量，而基于服务的架构增加了服务器的复杂性，并占用了它的内存和CPU资源。

有些人还提到了常见的HTTP服务或其他不满足RESTful体系结构或SOAP需求的服务。这些也可以分为基于服务的或基于资源的。它们的优点是实现起来更简单。只有当您知道您的服务永远不需要跨管理域集成时，才会使用这种方法，因为这种方法不会试图修复出现的集成问题。

这些类型的基于http的服务，特别是伪rest式服务仍然是最常见的类型。实现SOAP是复杂的，只有当你真的需要它时才应该使用它——例如，你需要一个跨域容易集成的服务，并且你希望它有一个服务接口。在某些情况下仍然需要这样做。真正的rest式服务也很难实现，尽管没有SOAP那么难。

SOAP(简单对象访问协议)和REST(表示状态传输)都有自己的美丽之处。所以我没有比较它们。相反，我试图描述我喜欢使用REST和SOAP的情况。

什么是有效载荷?

当数据通过Internet发送时，传输的每个单元都包括头信息和正在发送的实际数据。报头标识数据包的源和目的地，而实际数据被称为有效负载。通常，有效负载是代表应用程序携带的数据和目标系统接收的数据。

现在，举个例子，我要发一封电报，我们都知道电报的费用取决于某些词语。

那么告诉我下面提到的这两条信息，哪一条发的更便宜?

<name>Arin</name>

or

"name": "Arin"

我知道你的答案会是第二个，尽管两个都代表着同样的信息，第二个在成本方面更便宜。

所以我想说的是，在有效载荷方面，通过网络以JSON格式发送数据比以XML格式发送数据更便宜。

下面是REST相对于SOAP的第一个优点。SOAP只支持XML，但REST支持不同的格式，如文本、JSON、XML等。我们已经知道，如果我们使用Json，那么我们肯定会在负载方面处于更好的位置。

现在，SOAP只支持XML，但它也有自己的优势。

真的!如何?

SOAP以三种方式依赖于XML 信封——它定义了消息中的内容以及如何处理它。

一组编码规则的数据类型，最后的过程调用和响应的布局收集。

此信封通过传输(HTTP/HTTPS)发送，并执行RPC(远程过程调用)，并返回带有XML格式文档信息的信封。

重要的一点是SOAP的优点之一是使用“通用”传输，而REST使用HTTP/HTTPS。SOAP几乎可以使用任何传输来发送请求，但REST不能。因此，我们在这里获得了使用SOAP的优势。

正如我在上面一段“REST使用HTTP/HTTPS”中已经提到的，所以对这些词进行更深入的研究。

当我们谈论HTTP上的REST时，应用HTTP的所有安全措施都是继承的，这被称为传输级安全，它只在消息在线路内时保护消息，但一旦你在另一边传递它，你就不知道在到达数据将被处理的真正点之前它必须经过多少个阶段。当然，所有这些阶段都可以使用不同于HTTP的东西。所以Rest并不完全安全，对吧?

但是SOAP像REST一样支持SSL，它还支持WS-Security，这增加了一些企业安全特性。WS-Security提供了从创建消息到使用消息的保护。因此，对于传输级别的安全性，我们发现的任何漏洞都可以使用WS-Security来防止。

除此之外，由于REST受到HTTP协议的限制，因此它的事务支持既不符合ACID，也不能跨分布式跨国资源提供两阶段提交。

但是SOAP对短期事务的基于ACID的事务管理和对长期事务的基于补偿的事务管理都有全面的支持。它还支持跨分布式资源的两阶段提交。

我没有得出任何结论，但我更喜欢基于soap的web服务，而安全性、事务等是主要考虑的问题。

这里是“Java EE 6教程”，他们说，当满足以下条件时，RESTful设计可能是合适的。看一看。

希望你喜欢我的回答。