SOAP 现在是一种遗留技术吗？

Question

人们还在写SOAP services 还是已经通过了architectural shelf life 的技术？人们正在回归二进制格式吗？

Answer 1

SOAP 的替代方案不是二进制格式。

我认为您看到了将 WS-* 的复杂性抛在脑后转而支持 REST 和 JSON 的愿望激增，因为它们使用起来更简单，并且不需要成功使用框架。 WS-* 表面上试图解决的问题对大多数用户来说并不是问题，但无论如何他们都必须为复杂性付出代价。

Answer 2

我仍然编写基于 WS-* 的服务。有点令人惊讶的是，在尝试与能力较弱的开发人员进行互操作时，我遇到的麻烦更少了。这是因为如果我向他们发送一个 WSDL 文件，他们就知道如何通过他们的工具来启动它并获得一个他们可以调用的 API，同时幸福地不知道引擎盖下发生了什么。为了给客户提供 REST-ful 服务，我必须开始与他们谈论 HTTP 和 XML，他们实际上并不像他们认为的那样理解这些，然后我就开始头疼了。

换句话说，要在 REST 上取得成功，服务提供者和消费者都必须知道他们在做什么（他们可以保持简单，并提出一个出色的非 WS-* 解决方案）。使用 WS-* 技术，即使只有一方有线索，它仍然可以成功。

不过，我认为，比当前 WS 标准复杂得多的面向 REST 的标准最终会出现，而当这种情况发生时，类似的工具也将可用。

Answer 3

我根本不会考虑 SOAP 遗留问题。 REST 与 SOAP 实际上只是 COM/CORBA 与 HTTP POST/GET 等争论的延续。SOAP 只不过是用 C 和 C 定义的相同原则（合同、提供者、消费者等）的更新版本。 .只是 SOAP 似乎成功了（至少部分地），而其他两个失败了（可能是 SOAP 只是有一个更好的营销团队），也就是说，与它相比，SOAP 确实允许不同的系统相当容易地连接前辈。话虽如此，它仍然存在与 COM/CORBA 相同的缺点……它可能变得非常复杂。

我认为 REST 目前才刚刚重新流行起来。这不是什么新鲜事，人们只是在重新审视它。看看网络。它是 REST，并且已经存在多年。 5 年后，人们会回首往事，并说它是遗产，需要改变。这是软件开发的本质。一切都在循环中。

关于哪个更好的辩论就像制表符与空格的辩论一样。会有不同方面的人发誓一个更好。最终，他们都实现了相同的目标。当然，在某些情况下，一个解决方案会比另一个解决方案更好，但最终两者都不会 100% 更好。

Answer 4

我想是的。 RESTful 解决方案对绝大多数用例越来越敏感； SOAP 和其他 RPC 技术的复杂性不再值得付出努力。

Answer 5

我们使用的是 SOAP，但由于我们控制了两个消息传递端点（网络上连接到我们服务器的胖客户端），我们认为 XML 的“通用语言”并没有提供任何真正的好处。相反，我们正在尝试通过 Google 协议缓冲区进行二进制序列化，就像我们迄今为止所学的所有内容一样。这有点像 CORBA 风格，但不会像 CORBA 那样让我脾气暴躁。仍未找到最适合 RPC 层的方案，但可以肯定有效负载将是协议缓冲区。

我要说明的一点是，如果您控制对话的双方，则绕过 XML 税有显着的效率优势。

Answer 6

是的，有些人仍然是（现在是 2011 年！）。我认为主要原因是 MS WCF 自动生成 SOAP 绑定。惊恐的事件。

Answer 7

如果不考虑问题是什么，也就是上下文是什么，就不可能定义什么是最佳技术解决方案。 REST 和 SOAP 都有自己的位置。如果您有一个高流量站点和一个熟悉 REST 的开发受众，那么 SOAP 将是一个糟糕的选择，主要是因为消息大小非常臃肿。如果您的站点规模较小且开发预算适中，那么 SOAP 将是一个更好的选择，因为它可以从 WSDL 自动生成代理。为了进行公平的比较，应该提到的是，实现 REST 对话需要更多的开发时间，因此成本更高，这对你的老板来说是一个非常相关的事实。

虽然 SOAP 确实是一个更复杂的协议，但根据我的经验，这并不能转化为可维护性问题。这是因为消息基于 HTTP 并且可以像 REST 消息一样轻松调试，并且主要平台上可用的 SOAP 堆栈非常可靠。

如果您的需求包括联合消息安全等复杂项目，那么 SOAP 的复杂性当然是一个优势。另一方面，根据我的经验，这类要求并不常见。 WS 标准委员会可能容易受到一些 YAGNI 问题的影响。现在 Web 服务通信已经司空见惯，结果证明它比最初设想的更简单。