为什么在“企业”应用程序中使用SOAP覆盖JSON和自定义数据格式?[关闭]

imho,有一个很大的原因是每个人都坚持使用SOAP而不是JSON。对于每个JSON设置,您总是为每个项目创建自己的数据结构。我不是说数据是如何编码和传递的,而是数据格式是如何定义的,数据模型。

SOAP有一种行业成熟的方式来指定数据将在表单推车中是一个产品集合,并且每个产品都可以具有这些属性等。一个组合良好的WSDL文档确实有这样的作用。嘿,这是W3C规范。

JSON有类似的方法来指定这个数据结构。一个javascript类被认为是最常用的方法。一个javascript类并不是一个真正的数据结构,以任何一种不可知的、成熟的、广泛使用的方式。实际上,javascript只在一个环境(浏览器)中执行。

简而言之,SOAP是一种在成熟的格式化文档(WSDL)中指定数据结构的方法。杰森没有。

更新 :我不得不说,我对这个答案多年来获得的票数感到惊讶,特别是考虑到当时的准确性。我不想讨厌JSON,但在 reading a recent article 我继续坚持我以前的观点。同时,JSON-RPC似乎从标准格式的角度(2010年的2.0版提案)实际上被抛弃了,没有其他JSON协议看起来接近SOAP标准化的水平。(就个人而言,这并没有阻止我在生产环境中采用JSON-RPC2.0。我只是永远不会用它向财富500强公司求婚。)

显然,从内部使用的角度来看,JSON是非常棒的。轻量级。快。广泛使用。合理的人类可读性。但是对于经常合并多个数据流的企业来说。几十个部门之间的数据格式规范是必要的。XML是公认的领导者。

原因 对于 JSON很简单。它易于阅读,易于理解,开销很小,而且几乎每种语言都有实现。

把“企业”能力称为有点疯狂,imho。这只是一种数据交换格式。不管是SOAP、XML、JSON,不管怎样,它只是一种通信格式。

我承认,工具很好;自动生成的类很好。但另一方面,你会得到 许多 当你手工管理你的课程时,通常来说,这并不难做到。

在我看来,安全不是问题。您的数据格式应该(同样,imho)与您的安全性无关。这需要完全处于不同的水平。虽然SOAP有一些安全扩展等,但我认为在大多数情况下,它们只是提供了许多不必要的复杂性。有没有尝试过阅读一些WS-Security规范?伊克斯。只使用JSON+HTTPS怎么样?很简单,每个人都支持它,而且它像冠军一样工作……

现在,这并不是说它是解决每个问题的正确方法,但是如果你只是在寻找数据交换,我就被卖掉了。

就我个人而言,我喜欢JSON作为一种格式,并且一直使用它。

JSON确实需要比SOAP XML付出更多的努力,但它通常会产生更小的包,因此更具可扩展性。在调试、嗅探电线等过程中,它(在我的主观意见中)也非常容易阅读。

一个主要原因是 没有什么 因为技术原因。

许多“企业”系统正被出售给“企业”客户。客户需要肥皂,这就是他们得到的。

他们的原因是什么?有时这是非常实用的:他们的团队熟悉SOAP,并且他们有许多现有的SOAP服务(并且这个团队在交付产品之后会维护它)。有时不是这样:他们在某篇文章中读到它,然后就下定决心了。

除非数据很大或者结构复杂,否则我不会使用SOAP。JSON、Ajax、PHP甚至其他的都做得很好。

我正在用SOAP与Javaee通信( Jboss Ejb 3.1 @WebService 后端到 MS C# Winforms .

也许将来会有SOAP(版本X),它将使用压缩的JSON作为数据交换格式,从而使其快速、理想。

1. RESTful有利于简单的数据交换;
2. 非常适合交互式网页中的JavaScriptAjax请求。