代表性状态传输（REST）和简单对象访问协议（SOAP）
答案
关于 SOAP 和 REST 的简单说明
SOAP-“简单对象访问协议”
SOAP 是一种通过 Internet 传输消息或少量信息的方法。 SOAP 消息采用 XML 格式，通常使用 HTTP（超文本传输协议）发送。
休息 - 代表性状态转移
休息是在客户端和服务器之间发送和接收数据的一种简单方法，并且没有定义很多标准。您可以发送和接收 JSON，XML 甚至纯文本形式的数据。与 SOAP 相比，它的重量轻。
两种方法都被许多大型公司使用。这是一个偏好问题。我更喜欢 REST，因为它更易于使用和理解。
简单对象访问协议（SOAP）：
- SOAP 在 HTTP 或有时在 TCP / IP 的基础上构建 XML 协议。
- SOAP 描述了功能和数据类型。
- SOAP 是 XML-RPC 的后继产品，并且非常相似，但是描述了一种标准的通信方式。
- 几种编程语言都对 SOAP 提供了本机支持，通常可以向其提供 Web 服务 URL，并且可以在不需要特定代码的情况下调用其 Web 服务功能。
- 必须首先将发送的二进制数据编码为诸如 base64 编码的格式。
- 有几种与之相关的协议和技术：WSDL，XSD，SOAP，WS-Addressing
代表性状态转移（REST）：
- REST 不必通过 HTTP，但是我在下面的大部分内容都会带有 HTTP 偏见。
- REST 非常轻巧，它说一会儿，我们不需要 SOAP 创建的所有这种复杂性。
- 通常使用普通的 HTTP 方法，而不是描述所有内容的大型 XML 格式。例如，使用 HTTP GET 获取资源，使用 HTTP PUT 将资源放置在服务器上。要删除服务器上的资源，请使用 HTTP DELETE。
- REST 非常简单，因为它使用 HTTP GET，POST 和 PUT 方法来更新服务器上的资源。
- REST 通常最好与面向资源的体系结构 （ROA）一起使用。在这种思维方式下，一切都是资源，您将在这些资源上进行操作。
- 只要您的编程语言具有 HTTP 库（并且大多数语言都具有），您就可以非常轻松地使用 REST HTTP 协议。
- 二进制数据或二进制资源可以简单地根据其请求进行传递。
Google 上关于 REST 与 SOAP 的争论不休 。
我最喜欢的是这个 。 2013 年 11 月 27 日更新：Paul Prescod 的网站似乎已经离线，并且该文章不再可用，尽管可以在Wayback Machine上找到副本，也可以在CiteSeerX 上以 PDF 格式找到。
休息
我知道 REST 的主要思想非常简单。我们使用网络浏览器已有多年，并且已经看到了网站的简易性，灵活性，性能等。 HTML 网站使用超链接和表单作为用户交互的主要方式。他们的主要目标是让我们（客户）仅知道我们可以在当前状态下使用的那些链接。 REST 只是简单地说：“为什么不使用相同的原理通过我们的应用程序来驱动计算机，而不是人类客户？” 结合使用 WWW 基础架构的功能，您将获得构建强大的分布式应用程序的杀手级工具。
另一个可能的解释是针对数学思维的人。每个应用程序基本上都是一个状态机，业务逻辑动作是状态转移。 REST 的想法是将每个转换映射到对资源的某些请求上，并为客户端提供表示当前状态下可用转换的链接。因此，它通过表示和链接对状态机进行建模。这就是为什么它被称为代表状态转移的原因。
令人惊讶的是，所有答案似乎都集中在消息格式或 HTTP 动词用法上。实际上，消息格式根本没有关系，只要服务开发人员记录了消息，REST 就可以使用任何一种消息格式。 HTTP 动词仅使服务成为 CRUD 服务，但尚未实现 RESTful。真正将服务转变为 REST 服务的是将超链接（也称为超媒体控件）与数据一起嵌入服务器响应中，并且超链接的数量必须足以使任何客户端从这些链接中选择下一步操作。
不幸的是，除了Roy Fielding 的论文之外，很难在 Web 上的 REST 上找到正确的信息。 （他是派生 REST 的人）。我会推荐“REST in Practice” 这本书，因为它提供了有关如何从 SOAP 过渡到 REST 的全面分步教程。
肥皂
这是 RPC（远程过程调用）体系结构样式的可能形式之一。从本质上讲，它只是一项技术，它允许客户端通过服务边界（网络，进程等）调用服务器的方法，就像它们在调用本地方法一样。当然，它实际上在速度，可靠性等方面与调用本地方法不同，但是想法很简单。
比较一下
比较任何形式的 RPC 与 REST 时，传输协议，消息格式，xsd，wsdl 等详细信息都无关紧要。主要区别在于 RPC 服务通过在 RPC API 中设计自己的应用程序协议来重新发明自行车，该协议只有它自己才知道。因此，所有客户端都必须在使用服务之前了解此协议，并且由于所有请求的专有语义，因此无法构建通用结构（如缓存）。此外，RPC API 并不建议在当前状态下允许执行哪些操作，这必须从其他文档中得出。另一方面，REST 意味着使用统一的接口以允许各种客户端对 API 语义有所了解，并使用超媒体控件（链接）突出显示每种状态下的可用选项。因此，它允许缓存响应以扩展服务，并使无需额外文档即可轻松发现正确的 API 使用情况。
从某种意义上说，SOAP（与其他任何 RPC 一样）都是试图通过服务边界建立隧道，将连接媒体视为仅能够传输消息的黑匣子。 REST 是一个决定，要承认 Web 是一个巨大的分布式信息系统，可以按原样接受世界并学习掌握它而不是与之抗争。
当您同时控制服务器和客户端以及交互不太复杂时，SOAP 似乎对内部网络 API 很有用。开发人员更自然地使用它。但是，对于许多独立方使用的公共 API 来说，它既复杂又庞大，REST 应该更合适。但是最后的比较非常模糊。
更新资料
我的经验出乎意料地表明，REST 开发比 SOAP 更困难。至少对于. NET。尽管有像 ASP.NET Web API 这样的出色框架，但是没有能够自动生成客户端代理的工具。就像 “添加 Web 服务参考” 或 “添加 WCF 服务参考” 一样。必须手动编写所有序列化和服务查询代码。而且，那是很多样板代码。我认为 REST 开发需要与每个开发平台的 WSDL 和工具实现类似的东西。实际上，似乎有一个很好的基础： WADL或WSDL 2.0 ，但是似乎没有一个标准得到很好的支持。
更新（2016 年 1 月）
事实证明，现在有各种各样的 REST API 定义工具 。我个人的喜好是RAML 。
Web 服务如何工作
嗯，这是一个太笼统的问题，因为它取决于特定 Web 服务中使用的体系结构和技术。但是通常，Web 服务只是 Web 中的某些应用程序，可以接受来自客户端的请求并返回响应。它暴露在 Web 上，因此它是一个Web服务，通常 24/7 全天候可用，这就是为什么它是service的原因。当然，它为客户解决了一些问题（否则为什么有人会使用 Web 服务）。