7 回答
SOAP 的替代方案不是二进制格式。
我认为您看到了将 WS-* 的复杂性抛在脑后转而支持 REST 和 JSON 的愿望激增，因为它们使用起来更简单，并且不需要成功使用框架。WS-* 表面上试图解决的问题对大多数用户来说并不是问题，但他们必须为复杂性付出任何代价。
我仍然编写基于 WS-* 的服务。有点令人惊讶的是，在尝试与能力较弱的开发人员进行互操作时，我遇到的麻烦更少了。这是因为如果我向他们发送一个 WSDL 文件，他们就知道如何通过他们的工具来启动它并获得他们可以调用的 API，同时幸福地不知道引擎盖下发生了什么。为了给客户提供 REST-ful 服务，我必须开始与他们谈论 HTTP 和 XML，他们实际上并不像他们认为的那样理解，然后我开始头疼。
换句话说，要在 REST 上取得成功，服务提供者和消费者都必须知道他们在做什么（他们可以让事情变得简单，并提出一个很棒的非 WS-* 解决方案）。使用 WS-* 技术，即使只有一方有线索，它仍然可以成功。
然而，我认为，最终会出现比当前 WS 标准复杂得多的面向 REST 的标准，当这种情况发生时，类似的工具也将可用。
我认同。RESTful 解决方案对绝大多数用例越来越敏感；SOAP 和其他 RPC 技术的复杂性不再值得付出努力。
我根本不会考虑 SOAP 遗留问题。REST 与 SOAP 实际上只是 COM/CORBA 与 HTTP POST/GET 等争论的延续。SOAP 只不过是用 C 和 C 定义的相同原则（合同、提供者、消费者等）的更新版本。 . 只是 SOAP 似乎成功了（至少部分地），而其他两个失败了（可能是 SOAP 只是有一个更好的营销团队），也就是说，与它相比，SOAP 确实允许不同的系统相当容易地连接前辈。话虽如此，它仍然存在与 COM/CORBA 相同的缺点……它可能变得非常复杂。
我认为 REST 目前才刚刚重新流行起来。这不是什么新鲜事，人们只是在重新审视它。看看网络。它是 REST，并且已经存在多年。5 年后，人们会回首往事，并说它是遗产，需要改变。这是软件开发的本质。一切都在循环中。
关于哪个更好的辩论就像制表符与空格的辩论一样。会有不同方面的人发誓一个更好。最终，他们都实现了相同的目标。当然，在某些情况下，一个解决方案会比另一个解决方案更好，但最终两者都不会 100% 更好。
我们使用的是 SOAP，但是由于我们控制了两个消息传递端点（网络上连接到我们服务器的胖客户端），我们认为 XML 的“通用语言”并没有提供任何真正的好处。相反，我们正在尝试通过 Google 协议缓冲区进行二进制序列化，就像我们迄今为止所学的一切一样。这有点像 CORBA 风格，但不会像 CORBA 那样让我脾气暴躁。仍然没有找到最适合 RPC 层的方案，但可以肯定有效负载将是协议缓冲区。
我要说明的一点是，如果您控制对话的双方，那么在绕过 XML 税方面会有显着的效率优势。
如果不考虑问题是什么，或者说环境是什么，就不可能定义什么是最好的技术解决方案。REST 和 SOAP 都有自己的位置。如果您有一个高流量站点和一个对 REST 感到满意的开发受众，那么 SOAP 将是一个糟糕的选择，主要是因为消息大小非常臃肿。如果您有一个开发预算适中的小型站点，那么 SOAP 将是一个更好的选择，因为它可以从 WSDL 自动生成代理。为了进行公平的比较，应该提到实现 REST 对话需要更多的开发时间，因此成本更高，这对你的老板来说是一个非常相关的事实。
虽然 SOAP 确实是一个更复杂的协议，但根据我的经验，这并不能转化为可维护性问题。这是因为消息基于 HTTP 并且可以像 REST 消息一样轻松调试，并且主要平台上可用的 SOAP 堆栈非常可靠。
如果您的要求包括联合消息安全等复杂项目，那么 SOAP 的复杂性当然是一个优势。另一方面，根据我的经验，这类要求并不常见。WS 标准委员会可能容易受到一些 YAGNI 问题的影响。现在 Web 服务通信已经司空见惯，结果证明它比最初设想的更简单。
是的，有些人仍然是（现在是 2011 年！）。我认为主要原因是 MS WCF 自动生成 SOAP 绑定。惊恐的事件。