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

Question

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

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

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

所以实际问题是：

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

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

Answer 1

  

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

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

这些丰富的界面使得JavaScript成为一种非常流行的语言，而JSON显然已经成功，它的普及使其成为推翻“尖端支架”的最佳候选者。

但XML背后有着悠久的历史。这是一项成熟的技术，有很多accompanying specifications。 JSON正赶上那些。

虽然the draft specification已于2011年5月到期，但JSON架构支持者认为他们是have reached a pretty close to final version规范。那么谁知道JSON Schema的未来发展方向。

  

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

此PHP实现是否根据JSON Schema草案的最新版本验证JSON？如果是，是否需要其他实施？您是否需要大量实施来认证规范是否严重？这就像说XSLT 2.0 is not serious because Microsoft didn't bother to implement it。

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

总之，我想说的是JSON不能完全取代XML，反之亦然。 So use each technology where appropriate

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。我会同时使用它们。

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

干杯！

Answer 4

我发现这有用Google groups #json-schema和JSON Schema: specifying and validating JSON data structures。