JSON Schema 与 XML Schema 的比较及其未来答案

【问题标题】：JSON Schema compared with XML Schema and their futureJSON Schema 与 XML Schema 的比较及其未来
【发布时间】：2012-04-08 21:32:52
【问题描述】：

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

这种自然的解析/验证活动在 XML 中似乎很自然，这让我想知道为什么在 JSON 中不是这样。

我最终陷入了怀疑的境地。我应该追求我的 JSON 结构数据交换还是切换到 XML？ 我首先选择 JSON 是因为它的简单性和与 XML 相比不那么冗长的语法，但是如果我必须重新开发世界上所有现有的标准，这些论点就会变得更轻松。我还选择了 JSON，希望限制我的 Web 服务器和我的移动应用程序之间的通信大小。与 Comet 应用程序一起使用时，XMPP 似乎已被 Google、Facebook 等大公司实施和使用，用于实时聊天聊天文本或基于视频的消息。

所以实际的问题是：

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

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

【问题讨论】：

看起来其他人回答了你的实际问题，但我想指出，如果你只找到一个实现，你就会错过一些。例如这是 Java 中的一个：github.com/fge/json-schema-validator，我也看到了一些用 JavaScript 实现的。

标签： xml json xmpp jsonschema

【解决方案1】：

这种自然的解析/验证活动在 XML 中似乎很自然，这让我想知道为什么在 JSON 中不是这样。

请记住让 JSON 出名的原因：使用 JavaScript 编写的具有非常丰富的用户界面的 Web 应用程序。 JSON 是完美的，因为来自服务器的数据直接映射到 JavaScript 对象上；使用 Ajax 访问 GET URL 并返回一个对象，无需解析或其他任何操作。

这些丰富的接口使 JavaScript 成为一种非常流行的语言，而 JSON 显然也随之而来，它的流行使其成为推翻“尖括号”的最佳候选者。

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

虽然the draft specification 于 2011 年 5 月过期，但 JSON Schema 支持者认为他们 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.

【讨论】：

如果我冒犯了 IETF JSON 维护者，我深表歉意。我的想法来自对我实际研究的天真分析：第三稿，一段时间后过期，工业实施的承诺有限。我的意图纯粹是为了理解，为什么似乎没有人在服务器端（php）更广泛地实现这个东西。真正的问题是：我是否试图过度验证我的数据？如果不是，既然你提到它，那么你最喜欢的库是什么，它在验证 json 输入方面做得很好？最后感谢相关的 SO 问题（我错过了）。
@Alain：我知道您对这项技术的低采用率以及确实存在only one PHP implementation worth mentioning（它本身不活跃）这一事实很感兴趣，但这些事情有时会发生。 我认为 JSON 的流行推动了它在各种情况下的使用，而最佳实践却没有时间跟进。。至于验证，请记住 JSON 不是大多数语言的原生格式。这意味着 JSON 被转换为原生对象...
... 如果转换失败，您将获得第一次转换验证。如果转换通过，则该语言更适合验证本机对象而不是其表示。模式确实非常有用，因为它很早就进入了验证过程，但缺少模式并不是进行 JSON 验证的阻碍。

【解决方案2】：

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

虽然您可以用 JSON 和 XML 表示数据，但它们是完全不同的。我什至不会在这里尝试准确，但希望能给你正确的想法：

JSON 是一种轻量级的（反）序列化和传递键/值和值列表的方法。它轻巧、简单、方便，而且有些人认为它比 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 做同样的事情。你会发现你不能使用相同的成本约束。这就是为什么 XMPP 实现不可能在 JSON 中完成的原因。

也就是说，XML 有自己的负担。很难构建好的 XML 解析器。甚至很难使用 XML 进行简单的序列化。在解决长文档等问题时，人类可读性是头痛的委婉说法。

简而言之：

当您只在 JSON 中传递数据时非常简单。
当您开发的协议将由第三方以不同方式扩展时，XML 就是这种方式。
来回转换是个坏主意。您不能仅仅将 XML 转换为 JSON。

【讨论】：

因此，在我为我的数据找到许多客户端的地方，我应该使用 xml 来保护他们和我自己免受我们各自扩展的影响。好提议。感谢您详细的回复，它慢慢澄清了我的想法。我是否仍然对为什么没有一堆 JSON 模式库这样的东西感到困惑。无论我与谁（客户端、服务器、...）交谈，我不应该总是验证进来的内容吗？是我的要求太高还是开发团队不费心测试他们自己的服务器和客户端之间的损坏（被黑）数据？
您猜对了，很多网络应用程序不执行验证。当然这是一个不好的做法，当然你应该避免它。另一方面，没有对 JSON 的模式支持并不会阻止您进行验证。我认为对于任何实际应用来说，这对 JSON 来说都不是问题。
在json中实现你上面提到的例子的方法就是{"album": { "name":"The Contino Sessions"}}"，并通过{"album": { "name":"The Contino Sessions", "genre":"foobar"}}"扩展它

【解决方案3】：

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

【讨论】：

【解决方案4】：

有许多替代数据交换的方法，我们在这里研究了 2 种流行的技术。 XML 通常比 JSON 大，但 XML 更灵活，可以做更多的事情。就糖而言，就像可乐和健怡可乐一样。

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

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

HTTP 压缩还有助于保持 XML 文件的大小。

我说。对于复杂的数据，我将使用 XML，对于简单的数据，我将使用 JSON。两个我都会用。

未来呢？我会说我不知道。

干杯！

【讨论】：

我阅读了您的文章和其他文章。让我试着描述一下我的理解，并请确认我的假设。 + 使用来自我的服务器的 xml 响应会很痛苦，所以为了简化开发人员的工作，您将等效的 xml 转换为 JSON 对象，这成为在浏览器环境中操作的方便对象？好的，这是一个加分项。
+ 但是，重点是关于验证。服务器或客户端必须针对任何接收到的数据验证不同的质量。如果我没有针对我的断言进行测试，我无法处理任何数据，以确保我的服务器和我的客户端浏览器的安全性和健全性。那么，为什么它在 JSON 世界中仍然不存在呢？
数据验证：例如，这个数据结构是否平衡，是否缺少属性，是否有一些数据超出边界，我的数据是否在此过程中被黑客破坏或我从未纠正过的错误。我坚信（这可能是有争议的，所以请随时发表评论），如果我没有针对这些（以及更多）断言进行测试，我将无法处理任何数据，以确保我的服务器和我的客户端浏览器的安全性和健全性。