当JSON如此简单易用时,为什么要使用XML(SOAP)？

Question

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

此外,在简单的客户端 - 服务器应用程序(如与服务器连接的移动应用程序)中,SOAP可以提供优于JSON的任何优势吗？

如果有人能够考虑我提供的信息(如果有的话),可以在JSON和SOAP之间争取主要/突出的差异,我将非常感激.

Answer 1

我发现了SOAP的优点

• 每个人都坚持使用SOAP而不是使用JSON有一个重要原因.对于每个JSON设置,您总是为每个项目提供自己的数据结构.我不是说数据是如何编码和传递的,而是数据格式化格式是如何定义的,即数据模型.
• SOAP有一种行业成熟的方式来指定数据将采用以下形式:Cart是一个产品集合,每个产品都可以具有这些属性等.一个很好的WSDL文档确实有这个固定.哎呀,这是W3C规范.
• JSON具有类似的指定此数据结构的方法.作为执行此操作的最常见方式,我们会想到一个JavaScript类.JavaScript类实际上并不是一种不可知的,完善的,广泛使用的数据结构.哎呀,JavaScript实际上只在一个环境中执行,即浏览器.
• 简而言之,SOAP有一种在成熟格式的文档(WSDL)中指定数据结构的方法.JSON没有标准的方法来做到这一点.

如果要创建客户端应用程序并且使用SOAP完成服务器实现,则必须在客户端使用SOAP.

另见这里和这里

Answer 2

如今SOAP是一个完全矫枉过正的恕我直言.很高兴使用它,很高兴学习它,它很漂亮我们现在可以使用JSON.

SOAP和REST服务之间的唯一区别(无论是否使用JSON)是SOAP WS总是拥有自己的WSDL文档,可以很容易地转换为自描述文档,而在REST中,您必须自己编写文档(至少记录数据结构).以下是我对两者的缺点:&'

休息

优点

• 轻量级(无论如何:不需要服务器端或客户端扩展,不需要在这里和那里传输大块的XML)
• 自由选择数据格式 - 由您来决定是否可以使用普通TXT,JSON,XML,甚至创建自己的数据格式
• 大多数当前的数据格式(即使使用的XML)确保只通过HTTP传输真正需要的数据量,而对于5字节数据的SOAP,您需要1 kB的XML垃圾(夸大了,ofc,但是你得到了点)

缺点

• 即使有一些工具可以从docblock评论生成文档,如果想要获得一个好的文档,还需要以非常描述性的方式编写这样的评论.

肥皂

优点

• 有一个WSDL可以从甚至基本的docblock注释(甚至没有它们的许多语言)生成,这些注释很适合作为文档
  • 即使有一些工具可以使用WSDL来增强尝试这个请求界面(虽然我不知道任何这样的REST工具)
• 严格的数据结构

缺点

• 严格的数据结构
• 使用XML(仅!)进行数据传输,而每个请求包含大量垃圾,响应包含五倍以上的垃圾信息
• 对外部库的需求(对于客户端和/或服务器,虽然现在有这样的库已经是许多语言的本地部分,但人们总是倾向于使用某些第三方的)

总而言之,我没有看到更喜欢SOAP over REST(和JSON)的重要原因.两者都可以这样做,在几乎所有流行的Web编程语言中都有对JSON编码和解码的本机支持,并且使用JSON,您可以获得更多自由,并且可以从大量无用的信息垃圾中清除HTTP传输.如果我现在要构建任何API,我会使用REST和JSON.

Answer 3

我对这里看到的JSON趋势不以为然.虽然JSON是一个更容易的订单,但我敢说它非常有限.例如,SOAP WS不是最后一件事.实际上,在soap客户端/服务器之间,您现在拥有企业服务总线,基于加密的身份验证方案,用户管理,时间戳请求/回复等.对于所有这些,有一些巨大的软件平台提供围绕SOAP的服务(嗯, "Web服务")并将在XML中注入内容.因此虽然JSON对于小型项目来说可能已经足够了,并且在那里容易一个数量级,但我认为如果你将传输控制与内容分离(即你开发内容,实际的服务器,但是所有的传输都是管理的)它变得非常有限由另一个团队,另一个团队进行身份验证,由另一个团队部署).我不知道我在大公司的经历是否相关,但我会说JSON不会在那里生存.除了数据表示的基本需求之外,还有太多限制.所以问题不在于JSON RPC本身,问题在于它错过了额外的工具来管理复杂应用程序中出现的复杂性(并不是说你做的事情并不复杂,只是说软件反映了公司的复杂性.生产它)