我在一家中等规模的金融公司工作，我们所有的应用程序都使用SOAP相互交流，我们只使用JSON来处理来自网站的AJAX请求。
最近在一个新的项目规划会议上，有人问我为什么要使用SOAP进行应用程序间通信？为什么不使用JSON甚至自定义数据格式？在我心里，我觉得这些替代品不是“企业就绪”，但实际上我想不出一个非常有说服力的答案，为什么它们是坏的。
我能想到的SOAP的唯一两个优点是工具和安全性。
现代IDE（如Visual Studio）具有内置实用程序，可以从WSDL定义生成类，如果使用JSON或自定义数据格式，则无法获得这些类。在安全性方面，SOAP具有明确定义的安全标准，这些标准在其他数据格式标准中是不可用的。
你怎么看？你是否使用JSON作为应用程序之间的数据交换格式？答案 0 :(得分：9)
JSON的原因是简单性。它易于阅读，易于理解，开销小，并且几乎可用于所有语言。
打电话给“企业”能力有点疯狂，恕我直言。它只是一种数据交换格式。无论是SOAP，XML，JSON还是其他什么，它只是一种通信格式。
工具很好，我承认;自动生成的类很棒。但另一方面，当您手动管理课程时，您会获得很多的灵活性，而且通常情况下并不难。
在我看来，安全是一个非问题。您的数据格式应该（再次，恕我直言）与您的安全无关。这需要完全处于不同的水平。虽然SOAP有一些安全扩展等，但我认为在很大程度上，它们只是提供了许多不必要的复杂性。曾经尝试过阅读WS-Security的一些规范吗？让人惊讶。如何使用JSON + HTTPS - 简单，每个人都支持它，它就像一个冠军......
现在，这并不是说它是解决所有问题的正确解决方案，但如果你只是在寻找数据交换，那我就卖掉了。
就个人而言，我喜欢JSON作为格式，并且一直使用它。
答案 1 :(得分：1)
JSON确实需要更多的SOAP XML工作，但它通常会生成更小的数据包，因此更具可扩展性。它（在我的主观意见中）更容易阅读，同时调试，嗅探电线等。
答案 2 :(得分：1)
SOAP有一种行业成熟的方式来指定数据将采用以下形式：Cart是一个产品集合，每个产品都可以具有这些属性等。一个很好的WSDL文档确实有这个固定。哎呀，这是一个W3C规范。
JSON具有指定此数据结构的类似方法。作为执行此操作的最常见方式，我们会想到一个JavaScript类。 JavaScript类实际上并不是一种不可知的，完善的，广泛使用的数据结构。哎呀，JavaScript实际上只在一个环境中执行，即浏览器。
简而言之，SOAP是一种在成熟格式的文档（WSDL）中指定数据结构的方法。 JSON没有。
更新：我不得不说，由于当时的准确性，这个答案多年以来得到的低票数令我感到惊讶。我并不是故意讨厌JSON，但在reading a recent article之后，我继续支持我之前提出的观点。同时，JSON-RPC似乎实际上已从标准化格式的角度（2010年的2.0版提案）中放弃，并且没有其他JSON协议看似接近SOAP标准化的水平。 （就个人而言，这并没有阻止我在生产环境中使用JSON-RPC 2.0。我绝不会在向财富500强公司的提案中使用它。）
要明确，从内部使用的角度来看，JSON是伟大的。轻巧。快速。广泛使用。合理的人类可读性。但对于企业来说，经常合并多个数据流。并且数十个部门之间的数据格式规范是必要的。 XML是既定的领导者。
答案 3 :(得分：0)
由于技术原因，无任何的一个主要原因。
许多“企业”系统被出售给大型的“企业”客户。客户需要SOAP，这就是他们得到的。
他们的理由是什么？有时它非常务实：他们的团队熟悉SOAP，他们有许多现有的SOAP服务（这个团队会在交付后维护产品）。有时并非如此：他们在某篇文章中阅读了这些文章并且他们的思想已经完成了。
答案 4 :(得分：0)
除非数据很大或结构复杂，否则我不会使用SOAP。 JSON，AJAX，PHP甚至REST都做得很好。
答案 5 :(得分：0)
我正在使用SOAP从JavaEE（Jboss Ejb 3.1 @WebService）后端与MS C# Winforms进行通信。
将来可能会有SOAP（版本X）使用压缩的JSON作为数据交换格式，这将使其快速而理想。