为什么以及何时使用RESTful服务？
我知道如何创建WCF Web服务。但我无法理解何时使用基于SOAP的服务以及何时使用RESTful服务。我阅读了很多关于SOAP与REST的文章，但是，我还没有清楚地了解为什么以及何时使用RESTful服务。
为了便于在这些服务之间做出决定，有哪些具体要点？
答案 0 :(得分：9)
这是一个值得回答的问题，而简短的回答并不公正。忘记大多数人可能比REST更熟悉SOAP的事实，我认为这里有几个关键点：
首先，我建议在任何适合自然的地方使用REST。如果您的主要使用场景涉及读取和更新数据原子（“资源”），则REST提供更轻量级，可发现且简单明了数据访问方法。此外，使用REST构建真正瘦客户端（移动设备，JavaScript，甚至shell脚本）通常更容易。
例如：如果您的数据模型完全与客户有关，而您的主要操作涉及阅读客户并回写更改，那么REST就可以了。使用GET / POST / PUT / DELETE HTTP协议是使协议易于发现且易于使用的绝佳方法，即使对于不熟悉您的应用程序的人也是如此。
然而，这将我们带到第二点。
如果您需要提供具有查询功能的Web API，该怎么办？例如，典型情况可能是“让我获得5个最新客户”。在这种情况下，纯REST几乎不提供API可发现性。输入OData（www.odata.org），然后再次滚动;从这个观点来看，基于OData URI的查询语法在REST服务的正常极其简单的基于ID的寻址之上增加了一些众所周知的抽象。
但是，有些方面在REST方面难以代表。 第三点：如果您无法合理地对其进行建模，请考虑使用SOA。
例如，如果常见的使用场景涉及在工作流阶段（例如，“新客户”，“收到信用请求”，“信用批准”）之间转换客户，则使用REST对这些阶段进行建模可能会很复杂。是否应将不同阶段表示为实体中的属性值？或许，是否应将不同阶段建模为客户所在的容器？如果它是一个属性，你是否总是想在更新它时做一个完整的PUT？您是否应该使用自定义HTTP谓词（“APPROVE http://mysite/customers/contoso HTTP / 1.0”）？
这些是没有普遍答案的有效问题。所有东西都可以在REST中建模，但是在某些时候，抽象分解了很多，以至于很多REST的面向人类的好处（可发现性，易于理解）都会丢失。当然，技术优势（如所有HTTP级别的优点）仍然可以获得，但在大多数情况下，它们并不是真正的关键参数。
第四，也是最后一点，SOA模型简直做得很好。也许最重要的是交易。虽然它在WS- *世界中也是一个相当复杂的通用问题，但很少需要通用事务，并且通常可以用相当简单的原子操作替换。
例如，考虑一种情况，您希望创建一个允许在一个帐户下合并两个客户及其所有购买的操作。当然，所有这些都需要发生或不发生;典型的交易场景。在REST中对此进行建模需要付出巨大的努力。对于像这样的特殊场景，简单的SOA方法是创建一个在内部实现事务的操作（MergeCustomers）。
对于更高级的场景，WS- *堆栈提供了REST世界中不易获得的工具（包括WS-Transaction，WS-Security和诸如此类的东西）。虽然大多数API都不需要这些（或者更好地以更简单的方式实现它们），但我认为重写所有这些只是为了100％REST是值得的。
展望两全其美。对于绝大多数场景，在REST中使用基本CRUD并在SOA中提供一些专门操作是完全可以接受的。
此外，这些API可以设计为一起行动。例如，基于SOA的MergeCustomers操作应该返回什么？它可能会返回合并客户的序列化副本，但在大多数情况下，我会选择返回作为新合并客户的REST资源的URI。这样，即使SOA对于特定方案是必需的，您也总是只有一个客户表示。
以前的方法的缺点是它需要客户端支持REST和SOA。然而，这很少是一个真正的问题（除了纯粹的架构观点）。最简单的客户端通常具有REST功能，具有HTTP堆栈的定义，并且它们很少运行更复杂的操作。
当然，您的里程可能会有所不同。您的应用程序（及其客户端），本地策略和向后兼容性要求的需求通常似乎在正手中主导这些讨论，因此REST与SOA的讨论很少基于纯粹的技术优势。
答案 1 :(得分：3)
一个永恒的问题！ SOAP与REST ....
SOAP 非常棒，因为它具有工业强度，服务是以机器可读和可解释的方式自我描述的，例如，您的计算机可以读取，理解SOAP服务并为其创建客户端。 SOAP很棒，因为它的方法和它将传递的所有数据都被非常详细地描述和定义。但SOAP有点重 - 它需要大量的基础设施来支持它。 SOAP也主要是面向方法的，例如您可以通过在服务上执行方法来定义服务。
REST 更轻量级 - 它只使用已建立的HTTP协议和程序，因此任何具有HTTP堆栈（现在没有）的设备都可以访问REST服务。不需要SOAP重装。 REST也是资源 - 中心，例如您考虑资源，资源集合及其属性以及如何处理这些资源（因此您基本上回到了创建，读取，更新，删除的核心功能）。 REST目前没有任何机器可读的服务描述，因此您可以尝试查看，或者需要服务提供商提供的一些文档，以了解您手头有哪些资源。
我个人的底线：如果您想公开一些数据集，并且能够从任何设备访问它（并且能够从任何设备访问它），并且易用性比可靠性和其他企业级功能更重要，那么REST是要走的路。如果您需要认真的，企业对企业，定义明确，文档齐全的服务来实现可靠性，事务支持等等，那么您肯定会使用SOAP进入正确的轨道。
但我真的没有看到REST 独占或 SOAP方法 - 它们对于两者都是很好的场景。
答案 2 :(得分：2)
SOAP将为您提供更丰富的功能，您可以创建强类型服务，其中REST通常更轻量级，更容易运行。
编辑：如果你看一下ws- *标准，那就有很多东西http://www.soaspecs.com/ws.php。尽管如此，Visual Studio等开发工具使访问变得非常容易。通常，WS更多地用于企业SOA类型开发，而REST用于网站上的公共API（至少这就是我的想法）。
答案 3 :(得分：1)
Android（移动操作系统）不支持SOAP。当移动设备成为目标时，RESTful服务会更好。
在大多数情况下，我个人更喜欢RESTful服务，因为它们更轻量级，更易于调试和集成（除非您使用SOAP代码生成器）。
答案 4 :(得分：1)
未提及的一点是开销。我最近开展的一个REST项目涉及文件传输，允许的项目最多为2 GB。如果它是作为SOAP服务实现的，那么由于编码，数据会自动增加30％以上。 REST服务的开销是所有标头，其余是直接数据。