JSON Schema与XML Schema及其未来进行了比较

Question

我一直在寻找JSON模式标准及其相应的php实现.期待一些开源,我很惊讶,只找到一个PHP实现.我当时正在使用这种技术(JSON)和模式库来解析我传入的浏览器请求.

这种自然的解析/验证活动在XML中看起来很自然,让我想知道为什么JSON不是这种情况.

我最终遇到了疑问.我应该继续我的JSON结构数据交换还是切换到XML？ 与XML相比,我首先选择了JSON,因为它的简单性和冗长的语法,但如果我必须重新开发世界上所有现有的标准,这些参数会变得更轻松.我还选择了JSON,希望限制我的Web服务器和移动应用程序之间的通信大小.使用彗星应用程序,XMPP似乎被谷歌,Facebook这样的大品牌实施和使用,用于实时聊天聊天文本或基于视频的消息.

所以实际的问题是:

1. 对于那些想知道其流量发生了什么的可怜的Web服务器开发人员来说,JSON是JSON,并且专注于过度简单(不要误会,在这里,我包括我自己)？
2. 针对JSON模式的IETF草案是否是一项严肃的工作,因为服务器端(PHP)只存在很少的实现？
3. 我错过了什么,或者,最好的通信模式是将xml中的数据发送到服务器并期望json响应(javascript中存在许多json模式实现)？
4. 或者我只是面对实际的证据,开发人员社区没有很好地解决这个问题,因为使用JSON的Web开发人员不会深入测试他们的传入请求数据？

请帮助我理解,我在这里缺少一些经验？

Answer 1

这种自然的解析/验证活动在XML中看起来很自然,让我想知道为什么JSON不是这种情况.

记住使JSON成名的原因:具有用JavaScript编写的非常丰富的用户界面的Web应用程序.JSON非常适合这种情况,因为来自服务器的数据直接映射到JavaScript对象上; 用Ajax命中一个GET URL并获取一个对象,不需要解析或其他任何东西.

那些丰富的界面使JavaScript成为一种非常流行的语言,而JSON显然已经走过了它的普及,它成为推翻"尖端支架"的最佳候选者.

但XML背后有着悠久的历史.这是一项成熟的技术,有许多附带的规范.JSON正赶上那些.

虽然规范草案于2011年5月到期,但JSON Schema支持者认为他们已经达到了非常接近最终版本的规范.那么谁知道JSON Schema的未来发展方向.

我很惊讶,只找到一个PHP实现[...] IETF JSON模式草案是一项严肃的工作,因为服务器端(PHP)只存在很少的实现？

此PHP实现是否根据JSON Schema草案的最新版本验证JSON？如果是,是否需要其他实施？您是否需要大量实施来认证规范是否严重？这就是说XSLT 2.0并不严重,因为微软并不打算实施它.

至于您的上一个问题,需要验证传入的数据.你不接受用户请求并将其扔到服务器上并"希望它坚持".你验证它; 和JSON Schema不是验证JSON数据的唯一方法,因此不要假设使用JSON的Web开发人员不会深入测试其传入的请求数据.

总而言之,我想说的是JSON不能完全取代XML,反之亦然.因此,在适当情况下使用各种技术.

Answer 2

你在问题中提出了许多不同的问题,我不确定我是否正确地捕捉到了你真正想要的东西,但这里有一些想法:

虽然您可以用JSON和XML表示数据,但它们却完全不同.我不会在这里尝试准确,但希望能给你正确的想法:

• JSON是一种轻量级(de)序列化和传递键/值和值列表的方法.它轻巧,简单,方便,有些人认为比XML更具可读性.序列化/反序列化很容易用所有语言完成.

• XML是一种可扩展的标记语言,它不仅可以表示数据,还可以指定有关它们的规则(或协议,如果您喜欢).

这不仅与提供架构有关.由于您提到选择XML来表示其协议的XMPP,请考虑以下示例:

让我们说在一些基于XML的表示中,用于交换<album>定义元素的音乐信息.

<album>The Contino Sessions</album>

开发用于解析此XML的客户端将知道如何解释标记.现在,Foo Bar可能会更晚出现并建立在扩展它的协议上:

<album foobar:genre="Electronica">The Contino Sessions</album>

对foobar命名空间一无所知的老客户将继续像往常一样无视foobar:genre.那些被增强以理解foobar将解析类型注释的人.这通过示例说明了XML不仅仅是数据表示.试着想一想你如何用JSON做同样的事情.你会发现你不能用相同的成本.这就是为什么不可能在JSON中完成XMPP实现.

也就是说,XML带来了自己的负担.构建优秀的XML解析器很难.甚至很难使用XML进行简单的序列化.在弄清长篇文档等时,人类可读性是头痛的委婉说法.

简而言之:

• 当您只是传递JSON周围的数据时,这很简单.

• 当您开发一个协议时,第三方将以不同的方式扩展XML.

• 来回转换是一个不好的想法.您不能仅仅将XML转换为JSON.

Answer 3

数据交换有很多替代方案,我们在这里看两种流行的技术.XML通常比JSON大,但XML更灵活,可以做更多事情.就糖而言,喜欢COKE和健怡可乐.

如果您有服务XML的服务,那么为什么不创建一个适配器来将XML序列化为JSON并同时提供服务.我们只是想通过添加另一层来避免重新开发.

读一读. http://www.thomasfrank.se/xml_to_json.html

HTTP压缩还可以帮助保持XML文件在整个网络中保持较小.

我的发言权 对于复杂数据,我将使用XML,对于简单的数据,我将使用JSON.我会两个都用.

未来怎么样？我会说我不知道​​.

干杯!