我喜欢布莱恩·r·邦迪的回答。我只是想补充一点，维基百科对REST提供了清晰的描述。本文将它与SOAP区别开来。

REST是一种状态信息交换，尽可能简单地完成。

SOAP是一种使用XML的消息协议。

许多人从SOAP转向REST的主要原因之一是与基于SOAP的web服务相关的WS-*(称为WS splat)标准极其复杂。请参阅维基百科的规格列表。这些规范中的每一个都非常复杂。

编辑:由于某些原因链接不能正确显示。REST = http://en.wikipedia.org/wiki/REST

WS-* = http://en.wikipedia.org/wiki/WS-*

我喜欢布莱恩·r·邦迪的回答。我只是想补充一点，维基百科对REST提供了清晰的描述。本文将它与SOAP区别开来。

REST是一种状态信息交换，尽可能简单地完成。

SOAP是一种使用XML的消息协议。

许多人从SOAP转向REST的主要原因之一是与基于SOAP的web服务相关的WS-*(称为WS splat)标准极其复杂。请参阅维基百科的规格列表。这些规范中的每一个都非常复杂。

编辑:由于某些原因链接不能正确显示。REST = http://en.wikipedia.org/wiki/REST

WS-* = http://en.wikipedia.org/wiki/WS-*

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

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

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

这两种方法都被许多大型公司采用。这是个人喜好的问题。我更喜欢REST，因为它更容易使用和理解。

简单对象访问协议(SOAP):

SOAP builds an XML protocol on top of HTTP or sometimes TCP/IP. SOAP describes functions, and types of data. SOAP is a successor of XML-RPC and is very similar, but describes a standard way to communicate. Several programming languages have native support for SOAP, you typically feed it a web service URL and you can call its web service functions without the need of specific code. Binary data that is sent must be encoded first into a format such as base64 encoded. Has several protocols and technologies relating to it: WSDL, XSDs, SOAP, WS-Addressing

具象状态转移(REST):

REST need not be over HTTP but most of my points below will have an HTTP bias. REST is very lightweight, it says wait a minute, we don't need all of this complexity that SOAP created. Typically uses normal HTTP methods instead of a big XML format describing everything. For example to obtain a resource you use HTTP GET, to put a resource on the server you use HTTP PUT. To delete a resource on the server you use HTTP DELETE. REST is a very simple in that it uses HTTP GET, POST and PUT methods to update resources on the server. REST typically is best used with Resource Oriented Architecture (ROA). In this mode of thinking everything is a resource, and you would operate on these resources. As long as your programming language has an HTTP library, and most do, you can consume a REST HTTP protocol very easily. Binary data or binary resources can simply be delivered upon their request.

在谷歌上有关于REST和SOAP的无休止的争论。

我最喜欢的是这个。 2013年11月27日更新:保罗·普莱斯科德的网站似乎已经下线，这篇文章不再可用，不过可以在Wayback Machine上找到副本，或者在CiteSeerX上以PDF格式找到。

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 -简单对象访问协议是一个协议!

具象状态传输是一种架构风格!

SOAP是一种用于传输消息的XML协议，通常通过HTTP传输

REST和SOAP可以说不是相互排斥的。基于rest的体系结构可能使用HTTP或SOAP或其他通信协议。REST针对web进行了优化，因此HTTP是一个完美的选择。HTTP也是Roy Fielding论文中讨论的唯一协议。

尽管REST和SOAP显然非常不同，但这个问题确实说明了REST和HTTP经常是串联使用的事实。这主要是由于HTTP的简单性及其与RESTful原则的非常自然的映射。

REST基本原则

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

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

无状态的

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

缓存

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

统一的接口

All components must interact through a single uniform interface. Because all component interaction occurs via this interface, interaction with different services is very simple. The interface is the same! This also means that implementation changes can be made in isolation. Such changes, will not affect fundamental component interaction because the uniform interface is always unchanged. One disadvantage is that you are stuck with the interface. If an optimization could be provided to a specific service by changing the interface, you are out of luck as REST prohibits this. On the bright side, however, REST is optimized for the web, hence incredible popularity of REST over HTTP!

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

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