Fatal编程技术网
  • json/
  • 既然JSON如此简单且易于处理，为什么还要使用XML（SOAP）？

既然JSON如此简单且易于处理，为什么还要使用XML（SOAP）？

json soap

既然JSON如此简单且易于处理，为什么还要使用XML（SOAP）？,json,soap,Json,Soap,使用JSON接收和发送数据是通过简单的HTTP请求完成的。而在SOAP中，我们需要处理很多事情。解析XML有时也很困难。甚至Facebook也在Graph API中使用JSON。我仍然想知道为什么人们仍然应该使用肥皂？是否有任何理由或领域认为SOAP仍然是更好的选择？（尽管数据格式不同） 此外，在简单的客户机-服务器应用程序（如与服务器连接的移动应用程序）中，SOAP是否比JSON更具优势 考虑到我提供的信息（如果有的话），如果有人能指出JSON和SOAP之间的主要/显著差异，我将非常感激。我发

使用JSON接收和发送数据是通过简单的HTTP请求完成的。而在SOAP中，我们需要处理很多事情。解析XML有时也很困难。甚至Facebook也在Graph API中使用JSON。我仍然想知道为什么人们仍然应该使用肥皂？是否有任何理由或领域认为SOAP仍然是更好的选择？（尽管数据格式不同）

此外，在简单的客户机-服务器应用程序（如与服务器连接的移动应用程序）中，SOAP是否比JSON更具优势

考虑到我提供的信息（如果有的话），如果有人能指出JSON和SOAP之间的主要/显著差异，我将非常感激。

我发现了以下关于SOAP的优点

  • 有一个很大的原因是每个人都坚持使用肥皂而不是使用肥皂 JSON。在每一个JSON设置中，您都会提出自己的JSON设置 每个项目的数据结构。我不是说数据是如何编码的 和传递，但如何定义数据格式化格式 模型
  • SOAP有一种业界成熟的方法来指定数据将在 表单购物车是产品的集合，每个产品都可以 这些属性等等。一个组合良好的WSDL文档确实具有 这很好。见鬼，这是W3C规范
  • JSON有类似的方法来指定此数据结构。JavaScript 上课是最常见的方式。A. JavaScript类实际上不是任何类型的数据结构 不可知的，公认的，广泛使用的方式。见鬼，JavaScript真的吗 仅在一个环境（浏览器）中执行
  • 简而言之，SOAP有一种方法可以指定 成熟格式文档（WSDL）。JSON没有一种标准的方法来实现这一点
如果您正在创建一个客户端应用程序，并且您的服务器实现是用SOAP完成的，那么您必须在客户端使用SOAP

另外，请参见和

现在的SOAP完全是一种过度使用，伊姆霍。使用它很好，学习它很好，我们现在可以使用JSON很好

SOAP和REST服务之间的唯一区别（无论是否使用JSON）是SOAP WS始终有自己的WSDL文档，可以轻松地转换为自描述性文档，而在REST中，您必须自己编写文档（至少要记录数据结构）。以下是我对这两方面的缺点和优点：

休息 赞成的意见
  • 轻量级（无论如何：不需要服务器端或客户端扩展，不需要到处传输大块XML）
  • 数据格式的自由选择—由您决定是否可以使用纯TXT、JSON、XML，甚至创建自己的数据格式
  • 大多数当前的数据格式（即使使用了XML）都确保了只有真正需要的数据量才能通过HTTP传输，而使用SOAP处理5字节的数据时，您需要1KB的XML垃圾（夸张了，ofc，但您明白了）
欺骗
  • 即使有工具可以从docblock注释生成文档，如果想要获得一个好的文档，也需要以非常描述性的方式编写这样的注释
肥皂 赞成的意见
  • 有一个WSDL，它甚至可以从基本的docblock注释（即使没有注释，也可以使用多种语言）生成，可以很好地作为文档使用
    • 甚至有一些工具可以与WSDL一起使用，以提供一个增强的try-this请求接口（而我不知道REST是否有这样的工具）
  • 严格的数据结构
欺骗
  • 严格的数据结构
  • 使用XML（仅限于！）进行数据传输，而每个请求都包含大量垃圾信息，而响应包含的垃圾信息要多出五倍
  • 对外部库的需求（对于客户端和/或服务器，尽管现在已经有了这样的库，这已经是许多语言的本机部分，但人们总是倾向于使用一些第三方库）
总之，我不认为有什么大的理由比REST更喜欢SOAP（和JSON）。两者都可以做同样的事情，几乎每种流行的web编程语言都支持JSON编码和解码，使用JSON，您可以获得更多自由，HTTP传输可以从大量无用的信息垃圾中清除如果我现在要构建任何API，我会使用REST和JSON。

我不同意这里看到的JSON的趋势。虽然JSON是一种更简单的命令，但我敢说它相当有限。例如，soapws不是最后一件事。事实上，在soap客户机/服务器之间，您现在有了企业服务总线、基于加密的身份验证方案、用户管理、时间戳请求/回复等。对于所有这些，有一些大型软件平台围绕soap提供服务（嗯，“web服务”），并将在XML中注入内容。因此，尽管JSON对于小型项目来说可能已经足够了，而且在这方面更容易实现一个数量级，但我认为，如果将传输控制和内容解耦，JSON将变得非常有限（也就是说，你开发内容，实际的服务器，但是所有的传输都由另一个团队管理，认证由另一个团队管理，部署由另一个团队管理）。我不知道我在一家大公司的经历是否相关，但我想说JSON在那里无法生存。在数据表示的基本需求上有太多的限制。所以问题不在于JSON RPC本身，问题在于它缺少管理复杂应用程序中出现的复杂性的额外工具（并不是说你所做的并不复杂，只是软件反映了生产它的公司的复杂性）

我是一名PHP/JS开发人员。JSON的原因很简单。JSON==JS对象

SOAP很好，但很重。问题是。它值得吗？有时是，有时不是。在大多数情况下，不管怎样，最后都需要JSON

兵团使用SOAP，因为他们与t交换数据