c# - 我无法创建清晰的图片，为什么以及何时使用 RESTful 服务？

Question

这个问题在这里已经有了答案:





Why do we need RESTful Web Services?

(8 个回答)


8年前关闭。




为什么以及何时使用 RESTful 服务？

我知道如何创建 WCF 网络服务。但我无法理解何时使用基于 SOAP 的服务以及何时使用 RESTful 服务。我阅读了许多关于 SOAP 与 REST 的文章，但仍然没有清楚地了解为什么以及何时使用 RESTful 服务。

为了在这些服务之间轻松做出决定，有哪些具体要点？

Answer 1

这是一个有值(value)的问题，一个简短的回答是不公平的。忘记了大多数人可能比 REST 更熟悉 SOAP 的事实，我认为这有几个关键点:

首先，我建议在自然适合的地方使用 REST。 如果您的主要使用场景涉及读取和更新数据原子(“资源”)，则 REST 提供了一种更轻量、可发现和直接的数据访问方法。此外，使用 REST 构建真正的瘦客户端(移动设备、JavaScript，甚至 shell 脚本)通常更容易。

例如:如果您的数据模型都是关于客户的，并且您的主要操作涉及读取客户和写回更改，那么 REST 就可以了。使用 GET/POST/PUT/DELETE HTTP 协议(protocol)是使协议(protocol)易于发现和易于使用的极好方法，即使对于不熟悉您的应用程序的人也是如此。

然而，这将我们带到了第二点。

如果您需要提供具有查询功能的 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。然而，这很少是一个真正的问题(除了纯粹的架构角度)。根据具有 HTTP 堆栈的定义，最简单的客户端通常具有 REST 功能，并且它们很少运行更复杂的操作。

当然，您的里程可能会有所不同。您的应用程序(及其客户端)的需求、本地策略和向后兼容性要求似乎经常在这些讨论中占据主导地位，因此 REST 与 SOA 的讨论很少基于纯粹的技术值(value)。