人们仍在编写SOAP服务，还是已经过了其结构保存期限的技术？人们会返回二进制格式吗？

解决方案

回答

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

我认为我们看到了将WS- *的复杂性抛在后面而转向REST和JSON的渴望，因为它们使用起来更加简单，并且不需要成功使用框架。 WS- *表面上试图解决的问题对于大多数用户而言并不是问题，但是它们必须以任何方式为复杂性付出代价。

回答

我仍然写基于WS- *的服务。出乎意料的是，当我尝试与能力较弱的开发人员进行互操作时，他们遇到的麻烦减少了。这是因为，如果我向他们发送WSDL文件，他们就会知道如何通过他们的工具来启动它并获得可以调用的API，同时却很高兴地不知道背后发生了什么。为了给客户提供基于REST的服务，我必须开始与他们讨论有关HTTP和XML的内容，而他们实际上并没有像他们认为的那样理解它们，然后开始感到头疼。

换句话说，要想成功使用REST，服务提供商和使用者都必须知道他们在做什么(他们可以使事情变得简单，并提出一种出色的非WS- *解决方案)。使用WS- *技术，即使只有一方有线索，它仍然可以成功。

但是，我认为最终会出现比当前WS标准复杂得多的面向REST的标准，并且当这种情况发生时，也将提供类似的工具。

回答

我根本不会考虑SOAP传统。 REST与SOAP实际上只是COM / CORBA与HTTP POST / GET等争论的延续。SOAP仅仅是C和C(合同，提供者，消费者等)定义的相同原理的更新版本。 。仅仅是SOAP成功(至少部分成功)而其他两个失败了(可能是因为SOAP拥有一支更好的营销团队)，也就是说，与SOAP相比，SOAP确实确实允许连接到不同的系统。前辈。话虽如此，它仍然遭受与COM / CORBA相同的缺点……它可能变得非常复杂。

我认为REST现在刚刚恢复流行。这并不是什么新鲜事，人们只是在换个角度看。看网络。它是REST，已经存在了很多年。从现在开始的5年后，人们将回顾过去，对遗留物和改变需求说同样的话。这是软件开发的本质。一切都是按周期进行的。

关于哪个更好的争论将像标签与空格的争论一样。将会有不同方面的人发誓说一个更好。最终，他们两个都实现了相同的目标。当然，在某些情况下，一种解决方案会比另一种解决方案更好，但最终它们都不是100％的情况。

回答

我想是这样。 RESTful解决方案对于绝大多数用例而言越来越明智。 SOAP和其他RPC技术的复杂性已不再值得。

回答

我们使用的是SOAP，但是由于我们控制了两个消息传递端点(连接到服务器的Web上的胖客户端)，因此我们决定XML的"通用语言"并没有提供任何真正的好处。相反，我们正在尝试通过Google协议缓冲区进行二进制序列化，就像到目前为止学到的一切一样。它有点像CORBA风格，但并没有让我像CORBA那样脾气暴躁。仍然没有找到最适合RPC层的方法，但是可以肯定的是有效负载将是协议缓冲区。

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