开发者工具 · JSON 格式化程序和验证程序
JSON 如何取代 XML 作为 Web API 的默认格式
· 背景
json 标准 验证
二十年前 XML 是系统之间发送的任何内容的假定格式。这篇文章追踪了 JSON 如何在 Web API 中取代它、每种格式的设计目的以及为什么 XML 仍然主导着某些领域。
还剩一个 SOAP 端点
还剩下一个 SOAP 端点 — 一种在代码库中使用 XML 的集成，而其他所有内容都使用 JSON ，以及我们如何到达这里的问题。这种对比经常出现在客户端代码中：一条路径管理信封、命名空间和生成的类型，而较新的端点通过轻量级 HTTP 库交换普通对象。这一观察描述了当地的建筑，而不是普遍的年表。
格式化程序仅处理 JSON；跨格式转换属于单独的语法转换器面板。 JSON 的流行并不会使 XML 过时，本地漂亮打印也不会验证 API 合约。本文将历史采用与在此路线上实施的较窄行为区分开来。关于决定性日期、原因或整个市场替代的不受支持的历史说法被故意省略或纠正，而不是从当前的违约中推断出来。
XML 的用途
XML 的构建目的 — 具有混合内容、命名空间、模式和转换管道的文档。元素可以包含文本和子标记，属性可以携带元数据，命名空间限定的名称让词汇表共存。 XML Schema、XPath 和 XSLT 等技术支持跨以文档为中心的工作流程的验证、查询和转换。
当有效负载是出版物、签署的业务文档或可扩展的行业消息时，这些功能并不是无缘无故的。它们确实强加了比简单的对象和数组交换所需的更多概念。因此，比较等效示例应考虑契约，而不仅仅是字符数： XML 和 JSON 公开不同的建模工具，并且两种语法都不会自动提供正确的域语义。
浏览器本身可以做什么
浏览器本身可以做什么 — XMLHttpRequest 可以检索任一文本格式，并且浏览器提供 XML DOM 解析。早期的 JavaScript 代码有时会评估类似 JSON 的文本，当输入不受信任时，这是一种不安全的做法；标准化的 `JSON.parse` 后来提供了专用的解析器。解析后的 JSON 自然映射到 JavaScript 数组、对象、字符串、数字、布尔值和 null。
该映射减少了许多浏览器应用程序的仪式，但这并不能证明浏览器无法处理 XML 或仅由一个 API 决定采用。 XML DOM 保留元素、属性和命名空间，而不是自动变成普通对象。关于因果关系的历史主张需要超出实现便利性的来源，因此此处省略或纠正了不受支持的版本。
转折点 — 公共 Web API 提供 JSON 和 XML，然后仅提供 JSON，而 REST 在大多数新服务中取代了 SOAP
转折点 — 许多公共 Web API 与 XML 一起公开 JSON，并且许多后来的服务选择 JSON 作为其主要表示形式。轻量级 HTTP 样式对于应用程序 API 也变得很常见，而 SOAP 仍然保留在已建立的生态系统中。确切的市场份额、先行者和日期因来源而异，无法从此格式化程序存储库中确定。
因此，不受支持的历史主张被省略或纠正，而不是转换成一个整洁的单一原因故事。可防御的机制是互操作性压力：一旦团队围绕某种格式进行标准化，客户端库、文档、工具和邻近服务就会强化该格式。该反馈可以解释本地默认值，而无需声明 XML 消失或每个 REST API 使用 JSON。
转换成本
切换的成本 — JSON 在属性和子元素之间没有原生区别，没有混合内容模型，也没有注释语法。基本 JSON 语法也没有定义应用程序模式。需要合同的团队添加单独的系统，例如 JSON Schema 或 OpenAPI，每个系统都有自己的词汇表、工具和版本控制决策。
转换可能会丢失信息。重复的 XML 元素可能会变成数组，命名空间限定的名称需要表示，并且与标记交错的文本并不总是干净地变成简单的对象。更简单的有效负载语法将一些复杂性转移到外部契约或约定中；它不会使验证、演进和文档变得不必要。
XML 仍然获胜
XML 仍然获胜——发布工作流程受益于混合内容和既定的文档词汇表，而 Office 格式则打包 XML 部分来表示丰富的文档。成熟的金融和企业消息传递标准可能依赖于命名空间、模式、签名或长期工具投资。替换语法需要生态系统协调，而不仅仅是更短的示例有效负载。
XML 也很有用。 JSON 可以通过附加约定为这些领域提供服务，就像 XML 可以为普通 API 提供服务一样，但迁移价值必须超过合同和工具成本。面向浏览器的服务的受欢迎程度并不能证明每个表示问题的优越性，并且纠正或省略了不受支持的总位移的主张。
这不包括什么
这不包括 - 二进制替代品，例如 Protocol Buffers 和 MessagePack，它们在不同的条款上竞争。它们的线路尺寸、模式要求、流行为和工具需要单独评估。这也不能比较超媒体约定、传输协议或 API 风格； SOAP 与 REST 的比较不仅仅是 XML 与 JSON 的比较，而且任一表示形式都可以通过 HTTP 传输。
这也不是 API 采用的定量历史记录。关于日期、百分比、首次实施或全行业原因的精确陈述不受列出的存储库证据的支持，因此它们被省略或更正。相反，本文解释了可观察的格式功能和合理的工程后果，但没有将这些后果作为完整历史叙述的证据。
要点：JSON 赢得简单性，而不是完整性
要点：JSON 通过紧凑的数据模型、主流语言的直接支持和广泛的周边工具成为许多 Web API 的常见默认值，而不是因为它包含 XML 提供的所有功能。 XML 在文档结构、命名空间、转换或已建立的模式为中心的情况下仍然适用。格式选择遵循合同和生态系统，而不是通用排名。
ToolAcre 通过在此路径上解析、验证和漂亮打印 JSON 来反映 JSON 的窄模型；它不验证 API 语义或使 XML 过时。仅当定义的映射保留所需信息时才使用跨格式转换。对历史同样要小心：关于单一转折点或完全替代的不受支持的主张被忽略或纠正，留下可以辩护的机制和当前行为。