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

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

基于对象的体系结构从分层体系结构发展而来，遵循一个更宽松的模型。在这里，每个组件都是一个对象(通常称为分布式对象)。对象之间使用类似于远程过程调用的机制进行交互——当客户端绑定到分布式对象时，它将对象接口的实现加载到其地址空间中。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允许定义契约、WSDL(定义所支持的操作)、复杂类型等。 SOAP面向操作，而REST面向资源。 就我个人而言，对于企业内部应用程序之间的复杂接口，我会选择SOAP，而对于与外部世界的公共的、更简单的、无状态的接口，我会选择REST。

尽管SOAP和REST在HTTP协议上有相似之处，但SOAP是一组比REST更严格的消息传递模式。SOAP中的规则是相关的，因为没有它们我们就无法实现任何程度的标准化。REST作为一种体系结构风格不需要处理，而且本质上更通用。本着信息交换的精神，SOAP和REST都依赖于公认的法律，每个人都决定遵守这些法律。 SOAP和REST的选择取决于所使用的编程语言、所使用的环境和规范。

很多答案完全忘记了超媒体控件(HATEOAS)，这是REST的基础。其他一些人也提到了这个问题，但并没有很好地解释它。

本文将解释这两个概念之间的区别，而不涉及具体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那么难。

REST vs SOAP不是要问的正确问题。

REST与SOAP不同，它不是一个协议。

REST是一种架构风格，是一种针对基于网络的软件架构的设计。

REST概念被称为资源。资源的表示必须是无状态的。它通过某种媒体类型来表示。媒体类型的一些例子包括XML、JSON和RDF。资源由组件操作。组件通过标准的统一接口请求和操作资源。在HTTP的情况下，这个接口由标准的HTTP操作组成，例如GET, PUT, POST, DELETE。

@Abdulaziz的问题确实说明了REST和HTTP经常同时使用的事实。这主要是由于HTTP的简单性及其与RESTful原则的非常自然的映射。

REST基本原则

客户端和服务器之间的通信

客户机-服务器体系结构具有非常明显的关注点分离。所有以RESTful风格构建的应用程序原则上也必须是客户机-服务器。

无状态的

对服务器的每个客户机请求都要求完全表示其状态。服务器必须能够在不使用任何服务器上下文或服务器会话状态的情况下完全理解客户端请求。因此，所有的状态都必须保存在客户机上。

缓存

可以使用缓存约束，从而将响应数据标记为可缓存或不可缓存。任何标记为可缓存的数据都可以被重用作为对相同后续请求的响应。

统一的接口

所有组件必须通过一个统一的接口进行交互。因为所有组件的交互都是通过这个接口进行的，所以与不同服务的交互非常简单。界面是一样的!这也意味着可以孤立地进行实现更改。这些变化不会影响基本组件的交互，因为统一的接口总是不变的。一个缺点是你被界面束缚住了。如果通过更改接口可以为特定服务提供优化，那么您就不走运了，因为REST禁止这样做。然而，从好的方面来看，REST是为web优化的，因此REST在HTTP上非常流行!

上述概念代表了REST的定义特征，并将REST体系结构与其他体系结构(如web服务)区分开来。值得注意的是，REST服务是web服务，但web服务不一定是REST服务。

请参阅REST设计原则的博客文章，了解更多关于REST和上述要点的详细信息。

编辑:根据评论更新内容