为什么在"ENTERPRISE"应用程序中使用SOAP而不是JSON和自定义数据格式？

Question

我在一家中等规模的金融公司工作,我们所有的应用程序都使用SOAP相互交流,我们只使用JSON来处理来自网站的AJAX请求.

最近在一个新的项目计划会议中,有人问我为什么要使用SOAP进行应用程序间通信？为什么不使用JSON甚至自定义数据格式？在我心里,我觉得这些替代方案不是"企业就绪",但实际上我想不出一个非常有说服力的答案,为什么它们是坏的.

我能想到的SOAP的唯一两个优点是工具和安全性.

现代IDE(如Visual Studio)具有内置实用程序,可以从WSDL定义生成类,如果使用JSON或自定义数据格式,则无法获得这些类.在安全性方面,SOAP具有明确定义的安全标准,这些标准在其他数据格式标准中不可用.

你怎么看？你是否使用JSON作为应用程序之间的数据交换格式？

Answer 1

其原因为 JSON是简单.它易于阅读,易于理解,开销小,并且几乎可用于所有语言.

嘲笑某事"企业"能力有点疯狂,恕我直言.它只是一种数据交换格式.无论是SOAP,XML,JSON还是其他什么,它只是一种通信格式.

我承认,工具很好; 自动生成的类很棒.但另一方面,当您手动管理课程时,您会获得很大的灵活性,通常情况下,这并不难.

在我看来,安全性不是问题.您的数据格式应该(再次,恕我直言)与您的安全无关.这需要完全处于不同的水平.虽然SOAP有一些安全扩展等,但我认为在很大程度上,它们只是提供了许多不必要的复杂性.曾经尝试过阅读WS-Security的一些规范吗？让人惊讶.如何使用JSON + HTTPS - 简单,每个人都支持它,它就像一个冠军....

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

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

Answer 2

恕我直言，每个人都坚持使用 SOAP 而不是使用 JSON 有一个重要原因。对于每个 JSON 设置，您总是会为每个项目提出自己的数据结构。我指的不是数据如何编码和传递，而是如何定义数据格式，即数据模型。

SOAP 有一种行业成熟的方法来指定数据的格式为 Cart 是产品的集合，并且每个产品都可以具有这些属性等。精心组合的 WSDL 文档确实解决了这一点。哎呀，这是 W3C 规范。

JSON 有类似的方式来指定此数据结构。JavaScript 类是执行此操作的最常见方法。JavaScript 类实际上并不是一种不可知的、完善的、广泛使用的数据结构。哎呀，JavaScript 实际上只在一种环境中执行，即浏览器。

简而言之，SOAP 作为一种在成熟格式文档 (WSDL) 中指定数据结构的方式。JSON 没有。

更新：我不得不说，我对这个答案多年来获得的否决票数量感到惊讶，特别是考虑到它当时的准确性。我并不是有意讨厌 JSON，但在阅读了最近的一篇文章后，我继续坚持我之前提出的观点。与此同时，从标准化格式的角度来看，JSON-RPC 似乎实际上已被放弃（2.0 版是 2010 年的提案），并且没有其他 JSON 协议看起来接近 SOAP 的标准化水平。（就我个人而言，这并没有阻止我在生产环境中采用 JSON-RPC 2.0。我只是永远不会在向财富 500 强公司提出的提案中使用它。）

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