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

Question

我正在寻找JSON schema标准及其对应的PHP实现。希望能找到一些开源的东西，但惊讶地发现只有一个PHP实现。我打算使用这项技术(JSON)和schema库来解析我的浏览器请求。

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

我最终陷入了怀疑的境地。我应该继续追求我的JSON结构数据交换还是转向XML？我首先选择JSON是因为它相对于XML来说更加简单，语法上也更加简洁，但如果我必须重新开发世界上所有现有的标准，这些论点就变得更轻了。我也选择JSON，希望限制我的Web服务器和移动应用程序之间的通信大小。在玩弄冲击波应用程序时，XMPP似乎被大公司像Google、Facebook用于他们的实时聊天文本或基于视频的消息传递。

所以实际上的问题是：

1. JSON是否适合贫穷的Web服务器开发人员，他想要知道自己的流量情况，并专注于过度简化(不要误解，我也包括在内)?
2. 因为服务器端（PHP）只有少数几个实现，所以IETF对于JSON schema的草案是否是认真的工作呢？
3. 我是不是遗漏了什么，或者最好的通信模式是将数据以XML格式发送到服务器，然后期望JSON响应（许多JavaScript中存在JSON schema实现）？
4. 或者我只是面对了一个事实，即这个问题没有得到开发人员社区的很好解决，因为使用JSON的Web开发人员并没有深入测试他们的传入请求数据？

请帮助我理解，我是否缺乏一些经验？

- Alain

---

看起来其他人已经回答了你的实际问题，但我想指出，如果你只找到了一个实现，那么你可能错过了一些。例如，这里有一个Java实现：https://github.com/fge/json-schema-validator，我也看到了一些JavaScript实现。 - Eric

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 schema草案是一项严肃的工作吗？因为只有少数服务器端（PHP）实现存在？

这个PHP实现是否根据JSON Schema草案的最新版本验证JSON？如果是，是否需要其他实现？你需要很多实现来证明规范是认真的吗？这就像说XSLT 2.0不严肃，因为微软没有费心去实现它。

至于你最后的问题，传入数据需要进行验证。你不能接受用户请求并将其扔到服务器上，然后“希望它粘在那里”。你要验证它；而JSON Schema不是验证JSON数据的唯一方法，所以不要假设使用JSON的Web开发人员不会深入测试他们的传入请求数据。

总之，我想说的是JSON不能完全取代XML，反之亦然。因此，在适当的情况下使用每种技术。

- Bogdan

---

如果我冒犯了IETF JSON捍卫者，请接受我的道歉。我的想法来自于对实际研究的幼稚分析：第三个过期草案，工业实现的承诺有限。我的意图纯粹是为了理解，为什么没有人在服务器端（php）更广泛地实现这个东西。真正的问题是：我是否试图过度验证我的数据？如果不是，既然你提到了它，那么您更喜欢哪个库能够很好地验证JSON输入？最后感谢相关的SO问题（我错过了它）。 - Alain

@Alain：我知道你对这项技术的低采用率感到好奇，而且实际上只有一个值得一提的PHP实现（它本身也不活跃），但这些事情有时会发生。至于验证，记住JSON并不是大多数语言的本地格式。这意味着JSON被转换为本地对象... - Bogdan

如果转换失败，您将在第一次转换中获得验证。如果转换成功，则更适合使用语言来验证本地对象而不是其表示形式。模式确实非常有用，因为它可以尽早介入验证过程，但缺少模式并不是执行 JSON 验证的阻碍。 - Bogdan

Answer 2

您在问题中提出了许多不同的问题，我不确定是否正确地捕捉到了您真正想要的内容，但是以下是一些想法：

虽然您可以在JSON和XML中都表示数据，但它们确实是非常不同的。我不会试图准确地解释它们，但希望能给您正确的想法：

- JSON是一种轻量级的方式，用于序列化/反序列化和传递键/值和值列表。它很轻便、易用、方便，有人认为比XML更易读。所有语言都可以轻松地进行序列化/反序列化。 - XML是一种可扩展的标记语言，不仅表示数据，还指定了关于数据的规则（或协议，如果您喜欢这样说）。

这不仅仅与提供模式有关。由于您提到XMPP选择XML来表示其协议，请考虑以下示例：

假设在某个基于XML的表示中设计了一个用于交换音乐信息的元素。

<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。

- ggozad

---

所以，当我为我的数据寻找许多客户时，我应该使用XML来保护他们和我自己的扩展。这是一个很好的建议。感谢您详细的回复，它慢慢地澄清了我的想法。我仍然困惑的是为什么没有一堆JSON模式库之类的东西。无论我与谁交谈（客户端、服务器等），我都应该验证输入的内容吗？我的要求是否过于苛刻，或者开发团队是否不会在他们自己的服务器和客户端之间测试被破坏（被黑）的数据？ - Alain

你猜对了，很多网络应用程序没有进行验证。当然，这是一种不好的实践，当然你应该避免它。另一方面，缺少JSON模式支持并不妨碍你进行验证。我认为对于任何实际的应用程序来说，这都不是JSON的问题。 - ggozad

在JSON中实现你上面提到的例子的方式就是 {"album": { "name":"The Contino Sessions"}}"，并且可以通过 {"album": { "name":"The Contino Sessions", "genre":"foobar"}}" 进行扩展。 - speedplane

Answer 3

有许多数据交换的替代方案，我们在这里研究了两种流行技术。XML通常比JSON大，但XML更加灵活且功能更多。就像可口可乐和无糖可乐之间的区别一样。

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

请参阅http://www.thomasfrank.se/xml_to_json.html。

HTTP压缩也可以帮助保持XML文件在网络传输中的小型化。

我的建议是，对于复杂的数据我会使用XML，对于简单的数据我会使用JSON。我会同时使用两种格式。

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

祝好！

- DAEMYO

---

我读了你的文章和其他相关内容。让我试着描述一下我的理解，请确认我的假设是否正确。

• 从服务器获取XML响应并进行操作会很麻烦，因此为了简化开发人员的工作，您将等效的XML转换为JSON对象，这样在浏览器环境中就可以方便地操作该对象？好的，这是一个优点。

- Alain

然而，主要问题在于验证。服务器或客户端必须针对接收到的任何数据验证不同的质量。如果我没有根据我的断言进行测试，那么我无法处理任何数据，以确保我的服务器和客户端浏览器的安全性和健康性。那么，为什么 JSON 世界中仍然缺少这种验证机制呢？ - Alain

数据验证：例如，这个数据结构是否平衡，是否缺少属性，是否有一些数据超出了边界，我的数据是否在处理过程中被某个黑客或我从未纠正的错误所破坏。我坚信（这可能是有争议的，所以请随意发表评论），如果我没有针对这些（以及更多）断言对数据进行测试，那么我无法处理任何数据，以确保我的服务器和客户端浏览器的安全和健康。 - Alain

Answer 4

我发现这个Google groups #json-schema和JSON Schema: 指定和验证 JSON 数据结构很有用。

- Milindu Sanoj Kumarage