当以下任一情况为真时，优先使用 XML 而不是 JSON：

• 您需要消息验证
• 您正在使用 XSLT
• 您的消息包含大量标记文本
• 您需要与不支持 JSON 的环境进行互操作

当所有这些都成立时，优先使用 JSON 而不是 XML：

• 消息不需要验证，或者验证它们的反序列化很简单
• 您没有转换消息，或者转换它们的反序列化很简单
• 您的消息主要是数据，而不是标记文本
• 消息传递端点有很好的 JSON 工具

除非我需要使用 XML，否则我使用 JSON。它更容易理解，并且（因为它需要更少的配置开销）如果库在您的上下文中可用，那么它更容易进行读写编程，并且它们现在非常普遍。

当亚马逊第一次将他们的目录作为网络服务公开时，他们同时提供了 JSON 和 XML。大约 90% 的实施者选择了 JSON。

考虑到您已经在客户端执行 javascript 的特定情况，出于以下原因，我会使用 JSON：

• 由于 JSON 是 javascript 原生的，因此您必须在客户端编写更少的代码 - 只需eval()（或者更好的是JSON.parse()）JSON 字符串并获取您可以使用的对象。

• 同时，在客户端评估 JSON 会更高效，因此速度更快。

• JSON 序列化产生比 XML 更短的字符串。使用 JSON 将减少通过线路运行的数据量并提高这方面的性能。

这里有一些进一步的阅读：http : //www.subbu.org/blog/2006/08/json-vs-xml

我在 XML vs JSON relm 中遇到的其他一些事情：

JSON 非常适合

• 名称/值对
• 嵌套这些对

这意味着它倾向于喜欢数组或嵌套数组。但是 JSON 缺少两者

• 属性
• 命名空间

因此，如果您要组合两个或多个 JSON 服务，则可能存在潜在的命名空间冲突。也就是说，根据我的经验，在交换数据时，大约 90% 的事情都可以使用 JSON。

通常 JSON 更紧凑，解析速度更快。

在以下情况下首选 XML：

• 您需要在客户端处理数据，您可以利用 XSL 来实现这一点。很有可能 XML + XSL 链比 JSON + JavaScript 工作得更快，尤其是对于大块数据。
  • 一个很好的例子是将数据转换为 HTML 片段。
• 各种遗留案例：
  • 有一个现有的 XML 服务，由于某些原因，用 JSON 重写它很麻烦。
  • 在使用用户输入进行一些轻微处理后，您必须将此数据作为 XML 回传。

（几乎）XML 的一个重要案例：尝试检测何时发送 HTML 片段比发送原始数据更有益。AHAH可以在简单的应用程序中创造奇迹，但经常被忽视。通常这种风格假设服务器发送 HTML 片段，这些片段将被内联在网页中而不进行处理。

通常在 AHAH 案例中，CSS 被最大限度地利用来可视化地处理片段并实现简单的条件，例如使用特定于用户或特定于应用程序的设置隐藏/显示片段的相关部分。