为什么JSON使用XML（SOAP）如此简单易处理？
用JSON接收和发送数据是通过简单的HTTP请求完成的。 而在SOAP中，我们需要处理很多事情。 parsingXML也有时很难。 即使Facebook在Graph API中使用JSON。 我仍然想知道为什么还要使用SOAP？ 有没有什么理由或地区的SOAP仍然是一个更好的select？ （尽pipe数据格式）
而且，在简单的客户端 – 服务器应用程序（如与服务器连接的移动应用程序）中，SOAP可以比JSON有什么优势？
考虑到我提供的信息（如果有的话），如果有人可以争取JSON和SOAP之间的主要/显着差异，我将非常感激。
我发现以下SOAP的优点
- 每个人都使用SOAP而不是使用JSON，这是一个很大的原因。 随着每个JSON设置，你总是为每个项目提出自己的数据结构。 我不是指数据是如何编码和传递的，而是数据格式如何定义的，数据模型。
- SOAP具有一种行业成熟的方式来指定数据将以表单forms存储在一个Cart中，并且每个产品都可以具有这些属性等等。一个WSDL文档就好好地放在了一起。 嘿，这是一个W3C规范。
- JSON有类似的方式来指定这个数据结构。 一个JavaScript类是最常见的做法。 JavaScript类实际上并不是一种不可知论的，完善的，广泛使用的数据结构。 哎呀，JavaScript真的只能在一个环境中执行，就是浏览器。
- 简而言之，SOAP有一种在成熟格式化文档（WSDL）中指定数据结构的方法。 JSON没有这样做的标准方法。
如果您正在创build客户端应用程序，并且您的服务器实现是使用SOAP完成的，那么您必须在客户端使用SOAP。
也看到这里和这里
现在的SOAP是一个完整的矫枉过正，恕我直言。 很高兴使用它，很高兴能够学习它，现在我们可以使用JSON。
SOAP和REST服务（不pipe是否使用JSON）的唯一区别在于SOAP WS总是拥有自己的WSDL文档，在REST中可以很容易地将其转换为自描述文档，您必须为自己编写文档（至lesslogging数据结构）。 这是我的两个利弊：
rest
优点
- 轻量级（在所有方面：不需要服务器或客户端扩展，不需要在这里或那里传输大量的XML）
- 自由select数据格式 – 您可以决定是否使用普通的TXT，JSON，XML，甚至创build自己的数据格式
- 大多数当前的数据格式（甚至是使用XML）确保只有真正需要的数据量通过HTTP传输，而使用SOAP的5字节数据需要1kB的XML垃圾（夸大，ofc，但你得到了点）
缺点
- 即使有些工具可以从docblock注释中生成文档，但是如果想要获得良好的文档，也需要以非常具有描述性的方式编写这些注释
肥皂
优点
- 有一个WSDL可以从甚至基本的docblock注释（甚至在没有它们的许多语言中）生成，这很适合作为文档
- 即使有一些工具可以与WSDL一起工作来增强对这个请求接口的使用（虽然我不知道任何这样的REST工具）
- 严格的数据结构
缺点
- 严格的数据结构
- 使用XML（仅！）进行数据传输，而每个请求包含大量的垃圾，并且响应中包含的垃圾信息多五倍
- 对于外部库（对于客户端和/或服务器，虽然现在有这样的库已经是许多语言的本地部分，但是人们总是倾向于使用一些第三方库）
总之， 我没有看到比REST （和JSON） 更喜欢SOAP的大理由 。 两者都可以做同样的事情，几乎所有stream行的Web编程语言都支持JSON编码和解码，而JSON则拥有更多的自由，HTTP传输从大量无用的信息垃圾中清除。 如果我现在要构build任何API，我将使用REST和JSON。
对于我在这里看到的JSON的趋势，我有点不同意。 虽然JSON是一个更容易的命令，我敢说这是相当有限的。 例如，SOAP WS不是最后一件事。 事实上，在肥皂客户端/服务器之间，你现在有企业服务总线，基于encryption的authenticationscheme，用户pipe理，时间戳请求/回复等等。对于所有这些，有一些巨大的软件平台提供围绕SOAP的服务“networking服务”），并将注入东西在您的XML。 因此，虽然JSON对于小型项目来说足够了，并且在那里容易一个数量级，但是我认为，如果你有解耦的传输控制和内容（即你开发内容的东西，实际的服务器，但所有的传输都是pipe理的由另一个团队完成，再由另外一个团队进行validation，另一个团队进行部署）。 我不知道我在一家大公司的经验是否相关，但我会说JSON不会在那里生存。 除了数据表示的基本需求外，还有太多限制。 所以问题不在于JSON RPC本身，问题在于它错过了额外的工具来pipe理复杂应用程序中出现的复杂性（并不是说你所做的并不复杂，只是软件反映了公司的复杂性产生它）
