31

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

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

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

所以实际的问题是：

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

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

4

4 回答 4

11

这种自然的解析/验证活动在 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，或者相反。所以在适当的地方使用每种技术。

于 2012-03-25T17:41:10.807 回答
7

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

虽然您可以用 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。

于 2012-03-25T10:42:47.323 回答
5

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

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

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

HTTP 压缩还有助于通过网络保持 XML 文件较小。

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

未来如何？我会说我不知道​​。

干杯!

于 2012-03-25T03:29:32.773 回答
2

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

于 2012-03-25T03:44:04.833 回答