解决方案
XML 为机器对机器的数据提供了一套由标签、命名空间和模式构成的语法——表达力强,但也足够笨重,以至于发送一条简单的记录就意味着要写一份文档。JSON 走了相反的路:正如其主页所说,JSON 建立在两种结构之上,即名称/值对的集合和值的有序列表,并采用 C、C++、C#、Java、JavaScript、Perl 和 Python 程序员早已熟悉的书写惯例——这正是那些页面称其为理想的数据交换语言的原因。
该格式的渊源及其对 JavaScript 的脱离,都体现在它的标准化过程中。RFC 8259《JavaScript 对象表示法(JSON)数据交换格式》将其描述为一种轻量级、基于文本、与语言无关的数据交换格式,源自 ECMAScript 中所定义的 JavaScript 字面量——每个网络浏览器都能识别它,但它不属于其中任何一个。IETF 的 JSON 工作组推动它从 RFC 7159 走到 RFC 8259,使 JSON 于 2017 年 12 月成为互联网标准。
其结果是取代。API 曾经需要协商 XML 模式,如今则返回任何程序员一眼就能读懂的对象和数组——这是一种先被采用、之后才进入标准流程的格式,而不是需要标准流程去招募采用者。
它取得了什么成就
两种结构足以支撑每一个 API
它为何奏效
两种结构——对象和数组——几乎可以组合成程序在系统之间传递的每一种数据形态,因此该格式无需任何扩展机制。
从 JavaScript 字面量派生出的语法使该格式对增长最快的开发者群体而言即刻可读,而与语言无关的特性则让其他所有社区都留在其中。
无需模式或标签词汇表,因此 API 可以更改其载荷,而无需协调文档类型定义。
在被采用之后通过 IETF 进行标准化,既确保了互操作性,又没有强加那种使其前身缺乏吸引力的沉重负担。
可以借鉴什么
一种格式靠减法取胜:更少的构造意味着更少的分歧,而一种任何程序员无需文档就能读懂的数据格式,消除了那些阻碍更丰富的前身格式的阻力。
后续
RFC 8259 于 2017 年 12 月使 JSON 成为正式的互联网标准,而彼时它早已成为网络 API、配置和日志数据的默认交换格式——这是一种罕见的情况:一个格式由一个工作组对世界上既有行为予以批准而实现标准化。
从这里,追溯依据
参考来源
- RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format IETF (Datatracker) · datatracker.ietf.org ·
- Introducing JSON json.org · json.org