soap现在是一种遗留技术吗?

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

我认为您正在看到一种强烈的愿望,希望将ws-*的复杂性抛在后面,而支持rest和json,因为它们使用起来简单得多,不需要框架就能成功使用。对于大多数用户来说,ws-*表面上试图解决的问题并不是问题,但他们无论如何都要为复杂性付出代价。

我仍然编写基于ws-*的服务。有点令人惊讶的是,当我试图与能力较弱的开发人员交互操作时,我与他们的麻烦更少了。这是因为如果我给他们发送一个WSDL文件,他们知道如何通过他们的工具曲柄,并得到他们可以调用的API,而高兴地不知道引擎盖下面发生了什么。为了给客户提供一个完全休息的服务,我必须开始和他们谈论http和xml,他们真的不理解,正如他们认为的那样,然后我开始头疼。

换句话说,要想得到休息,服务提供者和消费者都必须知道他们在做什么(他们可以让事情变得简单,并且想出一个很棒的非WS-*解决方案)。使用WS-*技术,即使只有一方有线索,它仍然可以成功。

不过,我认为,与当前ws标准相比,面向rest的标准要简单得多,最终会出现,而且当出现这种情况时,也会有类似的工具可用。

我认为是这样.restful解决方案对于绝大多数用例来说越来越合理;soap和其他rpc技术的复杂性已经不值得再做这些工作了。

我根本不会考虑肥皂的传统。rest与soap实际上只是com/corba与http post/get等争论的延续。soap不过是用c和c(契约、提供者、消费者等)定义的相同原则的更新版本。只是soap似乎成功了(至少部分成功了),而其他两个都失败了(可能是soap有一个更好的营销团队),也就是说soap确实允许不同的系统连接起来,与它的前辈相比相当容易。也就是说,它仍然遭受COM/CORBA所做的同样的缺陷……它可能会变得非常复杂。

我认为休息现在正恢复正常。这不是什么新鲜事,人们只是在重新审视它。看看网络。已经休息了好几年了。5年后,人们会回首过去,说同样的话,这是一种遗产,需要改变。这是软件开发的本质。一切都是循环往复的。

关于哪一个更好的争论,将会像标签和空间的争论一样。会有不同方面的人发誓说一个更好。实际上,最终他们都达到了同样的目标。当然,在某些情况下,其中一种解决方案会比另一种更好,但最终在100%的情况下,这两种方案都不会优于其他方案。

我们使用的是soap,但是由于我们控制了两个消息传递端点(web上连接到服务器的厚客户端),我们决定xml的“通用语言”并没有提供任何真正的好处。相反,我们正在尝试通过google协议缓冲区进行二进制序列化,就像我们目前所学的一切一样。它有点CORBA风格,但并不像CORBA那样让我暴躁。仍然没有找到最适合rpc层的,但可以肯定的是,有效负载将是协议缓冲区。

我试图说明的一点是,如果您控制了对话的双方,那么绕过xml税将有显著的效率优势。

是的,有些人 仍然 是的(现在是2011年!)。我认为主要原因是ms wcf自动生成soap绑定。恐怖。

不考虑问题是什么,换句话说,上下文是什么,就不可能定义什么是最佳的技术解决方案。休息和肥皂都有自己的位置。如果您有一个高流量的站点和一个对rest很满意的开发受众,那么soap将是一个不好的选择,主要是因为消息太大了。如果您的站点规模小,开发预算适中,那么由于wsdl自动生成代理,soap将是一个更好的选择。为了进行公平的比较,应该提到实现rest对话需要更多的开发时间,因此成本更高,这对您的老板来说是一个非常相关的事实。

虽然soap确实是一个更复杂的协议,但根据我的经验,这并不能转化为可维护性问题。这是因为消息在HTTP上运行,可以像REST消息那样容易地进行调试,而在主要平台上可用的SOAP堆栈是非常可靠的。

如果您的需求包括诸如联邦消息安全性之类的复杂项,那么soap的复杂性当然是一个优势。另一方面,这些要求在我的经验中并不常见。ws标准委员会可能容易受到一些yagni问题的影响。现在,Web服务通信是司空见惯的,它原来是简单的,这是原先设想的。