Question

我的直觉告诉我，将一种格式放在另一种格式中是错误的，但我似乎无法提出具体原因。

<root>
 <stuff>
  thing
 </stuff>
 <more>
  <[!CDATA[{"a":["b","c"]}]]>
 </more>
</root>

而不是将其放入xml

<root>
 <stuff>
  thing
 </stuff>
 <more>
  <a>
   b
  </a>
  <a>
   c
  </a>
 </more>
</root>

这两个部分在逻辑上将被不同的代码解析，但作为交换格式，是否可以混合和匹配语法？

如果我们有一个解析JSON响应的现有端点，您的答案是否会改变？我们必须重新编码此端点以进行XML摄取。

Answer 1

由于使用两种格式的交换格式会给想要与您互动的人带来额外负担。现在他们需要一个XML解析器和一个JSON解析器。

这也使得人们更难以理解格式，因为他们在考虑文件的不同部分时必须精神上切换齿轮。

最后，您将无法轻松地同时查看整个结构。例如，您不能使用XPath来获取JSON位，也不能将整个响应视为JavaScript对象。通过混合两种格式，在操作数据时会出现“两个世界中最糟糕的”问题。

Answer 2

有点像数据库规范化辩论。使用纯XML（或规范化数据库模式）执行所有操作更清晰，更优雅，这样您就不会不必要地耦合到您的特定实现。但是如果你必须将XML转换为JavaScript对象（或者为每个该死的SELECT加入5个表），你最终可能会编写大量额外代码并导致不必要的性能命中。

这完全取决于你如何平衡便利与正式的正确性。如果这是一种XML交换格式，将由W3C标准化并由数百万人使用，那么亲爱的上帝，不要使用JSON。如果这是一个内部应用程序，只能由您自己编写的代码处理，然后拧紧它，只需将JSON扔到那里然后继续前进！

Answer 3

在我看来，XML是首选的数据传输表示，但是当涉及到地图和数组时，JSON更具表现力。将JSON嵌入到xml中以表示列表或映射时，我没有任何问题。

Answer 4

首先，我意识到在提出此问题8年后，我将发布帖子，但我保证我有这样做的正当理由。

我同意这是错误的所有原因，但是总是会出现边界情况。例如，我正在使用一些具有某些要求的旧版应用程序：

与外部系统的通信必须使用SOAP。
必须通过WSDL文件描述SOAP通信。
我们的系统必须摄取并编译WSDL文件才能使用，该文件会生成一堆已编译的Java类和方法。
如果WSDL已更新，我们的系统必须重新编译WSDL，这需要遵循FULL更改过程，这可能需要几个月的时间。
需要从我们那里获取SOAP数据的“他们的系统”是由一个完全独立的团队开发和维护的，并且存在各种障碍，阻碍了这两个团队进行实际的协作。（基本上，我们有机会在墙上扔一些东西，他们可以根据需要使用和扩展它；任何来回的动作都会使该项目延迟数月。）
以上因素均不可更改或质疑。

考虑到所有这些因素，我认为XML内的JSON是解决此特定问题的绝对最佳方法。这使我们在数据中仍然具有有意义的参数，同时避免了WSDL中的任何将来更改。

Answer 5

这不是天生的错误。如果您有这样做的理由，而替代方法更糟，那么您应该这样做。由于总是，需要根据运行的环境来判断解决方案（该死的学术界）。

就我而言，我有一个具有RESTful JSON API的全局数据库，这是一项欧盟法规，要求我必须创建一个本地副本，如果无法访问全局数据库，则可以从该副本访问数据以及基于SOAP和XML的基础架构。

我们仅需要百字段JSON记录中的五个字段即可进行日常操作。因此，不，我不会假装纯粹主义会带来好的解决方案，并向我们的API基础结构引入全新的标准。我将提取我需要的几个字段，并将其余字段作为JSON封装在CDATA部分中返回。

当然，我们的客户端应用程序不使用XML解析器，因此这不需要它们使用两个解析器。他们使用为他们进行解析的SOAP框架。