Rest & Soap 事务能力

Question

在一次采访中，面试官问，什么是事务能力，除了肥皂和休息之外，什么是具有事务能力的？

你能用简单的方式解释一下吗？

提前致谢，

Answer 1

当我遇到类似问题时遇到了这些参考资料。希望对您有所帮助。

• 来自http://spf13.com/post/soap-vs-rest

  WS-AtomicTransaction 需要服务上的 ACID 事务，您将需要 SOAP。虽然 REST 支持事务，但它并不像 全面且不符合 ACID。幸运的是 ACID 交易 在互联网上几乎没有意义。 REST 受 HTTP 限制 本身不能提供跨分布式的两阶段提交 事务性资源，但 SOAP 可以。互联网应用程序通常不会 需要这种级别的事务可靠性，企业应用程序 有时会。

• 来自https://msdn.microsoft.com/en-us/magazine/dd942839.aspx

  交易呢？

  这是 SOAP 和 WS-* 明确支持的另一个领域 “高级”功能而 REST 没有。 WS-原子事务 支持分布式两阶段提交事务语义 基于 SOAP 的服务。 REST 不支持分布式事务。 一般来说，如果你想要像交易这样的东西 RESTful 系统，你创建一个新资源。 （创建新资源 每当您遇到 RESTful 系统的问题时，通常都能解决 大多数问题。）您可以拥有一个名为 Transaction 的资源。当你的 客户需要做一些交易性的事情（比如转账 在两个银行账户之间），客户端创建一个 Transaction 资源 指定所有受影响的正确资源（在我的示例中， 两个银行帐户）通过对事务工厂 URI 执行 POST。这 然后客户端可以通过向事务发送 PUT 来执行更新 URI 并通过向 URI 发送 DELETE 来关闭事务。

  当然，这需要一些手工编码和显式 控制您的系统，而 WS-Atomic Transactions 系统是 更自动，因为（在 Windows 通信的情况下 Foundation）它与您的运行时管道相关联。

  如果您的系统绝对需要跨平台的原子事务语义 多样化的系统，WS-Atomic Transactions 可能是要走的路。 以这种方式使用分布式事务可能聪明也可能不聪明 因为它增加了两个系统之间的耦合并创建 如果您不控制两端的代码，则可能会出现问题。 但最重要的是为正确的使用正确的工具 工作（一旦你弄清楚什么是正确的工作）。为保卫 REST，我认为可以公平地说，鉴于今天的分布式， 面向服务的架构，将两个端点如此紧密地耦合在一起 使用分布式事务可能不是最好的设计。在 另一方面，某些情况需要这种类型的功能，并且 如果需要，请使用 SOAP 和 WS-Atomic Transactions。