这是你能找到的最简单的解释。

这篇文章以丈夫对妻子的叙述为例，丈夫用纯外行的语言向妻子解释REST。一定要读!

如何向我的妻子解释休息(原始链接) 如何向妻子解释休息(2013-07-19工作链接)

SOAP的问题在于它与HTTP栈背后的理想相冲突。任何中间件都应该能够在不了解请求或响应内容的情况下处理HTTP请求，但例如，常规的HTTP缓存服务器如果不知道SOAP内容的哪些部分与缓存有关，则无法处理SOAP请求。SOAP只是使用HTTP作为它自己的通信协议的包装器，就像代理一样。

REST

I understand the main idea of REST is extremely simple. We have used web browsers for years and we have seen how easy, flexible, performing, etc web sites are. HTML sites use hyperlinks and forms as the primary means of user interaction. Their main goal is to allow us, clients, to know only those links that we can use in the current state. And REST simply says 'why not use the same principles to drive computer rather than human clients through our application?' Combine this with the power of the WWW infrastructure and you'll get a killer tool for building great distributed applications.

另一种可能的解释是针对具有数学思维的人。每个应用程序基本上都是一个状态机，业务逻辑操作是状态转换。REST的思想是将每个转换映射到某个资源的请求上，并向客户端提供表示当前状态下可用转换的链接。因此，它通过表示和链接对状态机建模。这就是为什么它被称为具象状态传输。

It's quite surprising that all answers seem to focus either on message format, or on HTTP verbs usage. In fact, the message format doesn't matter at all, REST can use any one provided that the service developer documents it. HTTP verbs only make a service a CRUD service, but not yet RESTful. What really turns a service into a REST service are hyperlinks (aka hypermedia controls) embedded into server responses together with data, and their amount must be enough for any client to choose the next action from those links.

不幸的是，除了Roy Fielding的论文，在Web上很难找到关于REST的正确信息。(他是REST的发明人)。我推荐《REST in Practice》这本书，因为它提供了一个全面的循序渐进的教程，教你如何从SOAP演进到REST。

SOAP

这是RPC(远程过程调用)体系结构样式的一种可能形式。本质上，它只是一种允许客户端通过服务边界(网络、进程等)调用服务器方法的技术，就像调用本地方法一样。当然，它实际上与调用本地方法在速度、可靠性等方面有所不同，但思想就是这么简单。

相比

The details like transport protocols, message formats, xsd, wsdl, etc. don't matter when comparing any form of RPC to REST. The main difference is that an RPC service reinvents bicycle by designing it's own application protocol in the RPC API with the semantics that only it knows. Therefore, all clients have to understand this protocol prior to using the service, and no generic infrastructure like caches can be built because of proprietary semantics of all requests. Furthermore, RPC APIs do not suggest what actions are allowed in the current state, this has to be derived from additional documentation. REST on the other hand implies using uniform interfaces to allow various clients to have some understanding of API semantics, and hypermedia controls (links) to highlight available options in each state. Thus, it allows for caching responses to scale services and making correct API usage easily discoverable without additional documentation.

在某种程度上，SOAP(与任何其他RPC一样)试图通过服务边界进行隧道，将连接媒体视为只能传输消息的黑盒。REST决定承认Web是一个巨大的分布式信息系统，接受世界的现状并学会掌握它，而不是与之对抗。

当您同时控制服务器和客户端，并且交互不太复杂时，SOAP似乎非常适合内部网络api。开发人员更自然地使用它。然而，对于一个被许多独立方使用的公共API来说，它既复杂又庞大，REST应该更适合它。但最后这个比较非常模糊。

更新

My experience has unexpectedly shown REST development to be more difficult than SOAP. At least for .NET. While there are great frameworks like ASP.NET Web API, there's no tooling that would automatically generate client-side proxy. Nothing like 'Add Web Service Reference' or 'Add WCF Service Reference'. One has to write all serialization and service querying code by hand. And man, that's lots of boilerplate code. I think REST development needs something similar to WSDL and tooling implementation for each development platform. In fact, there seems to be a good ground: WADL or WSDL 2.0, but neither of the standards seems to be well-supported.

更新(2016年1月)

事实证明，现在有各种各样的REST API定义工具。目前我的个人偏好是RAML。

Web服务如何工作

嗯，这是一个过于宽泛的问题，因为它取决于特定web服务中使用的架构和技术。但一般来说，web服务只是web中的某个应用程序，它可以接受来自客户机的请求并返回响应。它暴露在网络上，因此它是一种网络服务，它通常是全天候可用的，这就是为什么它是一种服务。当然，它为客户端解决了一些问题(否则为什么有人会使用web服务)。

我想这是我能解释得最简单的了。请，任何人都欢迎纠正我或补充这一点。

SOAP是一种消息格式，用于断开连接的系统(如通过internet)交换信息/数据。它处理来回的XML消息。

Web服务传输或接收SOAP消息。它们的工作方式因所用语言不同而不同。

基于soap的Web服务 简而言之，基于soap的服务模型将世界视为一个由相互平等的对等点组成的生态系统，这些对等点不能相互控制，但必须通过遵守已发布的契约来共同工作。这是有效的 混乱的现实世界的模型，以及基于元数据的契约形成SOAP服务接口。

我们仍然可以将SOAP与基于xml的远程过程调用相关联，但是基于SOAP的Web服务技术已经成为一种灵活而强大的消息传递模型。

SOAP假定所有系统都是独立的，并且没有系统知道其他系统的内部信息和内部功能。 这样的系统最多能做的就是互相发送消息，并希望它们能被采取行动。系统发布它们承诺遵守的契约，而其他系统依赖这些契约与它们交换消息。

Contracts between systems are collectively called metadata, and comprise service descriptions, the message exchange patterns supported and the policies governing qualities of service (a service may need to be encrypted, reliably delivered, etc.) A service description, in turn, is a detailed specification of the data (message documents) that will be sent and received by the system. The documents are described using an XML description language like XML Schema Definition. As long as all systems honor their published contracts, they can inter operate, and changes to the internals of systems never affect any other. Every system is responsible for translating its own internal implementations to and from its contracts

REST -具象状态传输。物理 协议是HTTP。基本上，REST是指web上所有可以通过URL唯一识别的不同资源。可以在这些资源上执行的所有操作都可以用一组有限的动词(“CRUD”动词)来描述，这些动词又映射到HTTP动词。

REST的“重量级”比SOAP少得多。

web服务的工作

关于SOAP和REST的简单解释

SOAP -“简单对象访问协议”

SOAP是一种在Internet上传输消息或少量信息的方法。SOAP消息是XML格式的，通常使用HTTP(超文本传输协议)发送。

休息-具象状态转移

Rest是一种在客户端和服务器之间发送和接收数据的简单方法，它没有定义很多标准。您可以以JSON、XML甚至纯文本的形式发送和接收数据。与SOAP相比，它是轻量级的。