| 互联网工程任务组 | A. Wright，编辑 |
| 互联网草案 | |
| 预期状态：信息性 | H. Andrews，编辑 |
| 失效日期：2018 年 9 月 20 日 | Cloudflare，Inc. |
| 2018 年 3 月 19 日 |
JSON 架构：用于描述 JSON 文档的媒体类型
draft-handrews-json-schema-01
JSON 架构定义了媒体类型 "application/schema+json"，这是一种基于 JSON 的格式，用于描述 JSON 数据的结构。JSON 架构断言 JSON 文档必须是什么样子，从 JSON 文档中提取信息的方法以及如何与 JSON 文档交互。媒体类型 "application/schema-instance+json" 为 "application/schema+json" 提供了更丰富的功能集成，超出了 "application/json" 文档所能提供的范围。
此草案的议题列表可以在 <https://github.com/json-schema-org/json-schema-spec/issues> 找到。
有关更多信息，请参见 <https://json-schema.fullstack.org.cn/>.
要提供反馈，请使用此问题跟踪器，主页上列出的通信方式或通过电子邮件联系文档编辑。
本互联网草案完全符合 BCP 78 和 BCP 79 的规定提交。
互联网草案是互联网工程任务组 (IETF) 的工作文档。请注意，其他组也可能将工作文档作为互联网草案分发。当前互联网草案的列表在 http://datatracker.ietf.org/drafts/current/ 上。
互联网草案是有效的草案文档，最长有效期为六个月，并且可能会在任何时间被其他文档更新、替换或废弃。不建议将互联网草案用作参考材料或引用，除非以“正在进行的工作”的形式引用。
本互联网草案将于 2018 年 9 月 20 日过期。
版权所有 (c) 2018 IETF 信托和被识别为文档作者的人员。保留所有权利。
本文件受 BCP 78 和 IETF 信托的《与 IETF 文档相关的法律条款》(http://trustee.ietf.org/license-info) 约束，这些条款在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包含简化 BSD 许可证文本，如信托法律条款第 4.e 节所述，并且按简化 BSD 许可证中所述的方式提供，不提供任何担保。
JSON 架构是一种用于定义 JSON 数据结构的 JSON 媒体类型。JSON 架构旨在定义 JSON 数据的验证、文档、超链接导航和交互控制。
本规范定义了 JSON 架构的核心术语和机制，包括通过引用指向另一个 JSON 架构、反引用 JSON 架构引用以及指定正在使用的词汇表。
其他规范定义了关于验证、链接、注释、导航和交互进行断言的词汇表。
本文件中使用的关键术语“必须”、“禁止”、“必需”、“应”、“不应”、“建议”、“不建议”、“推荐”、“可能”和“可选”应按 RFC 2119 [RFC2119] 中所述进行解释。
本文件中使用的术语“JSON”、“JSON 文本”、“JSON 值”、“成员”、“元素”、“对象”、“数组”、“数字”、“字符串”、“布尔值”、“真”、“假”和“空”应按 RFC 7159 [RFC7159] 中所述进行解释。
本文件建议采用一种新的媒体类型 "application/schema+json" 来标识用于描述 JSON 数据的 JSON 架构。它还建议采用一种额外的可选媒体类型 "application/schema-instance+json"，以提供额外的集成功能。JSON 架构本身是 JSON 文档。本规范及其相关规范定义了关键字，使作者能够以多种方式描述 JSON 数据。
JSON 架构描述了 JSON 文档的结构（例如，必需属性和长度限制）。应用程序可以使用此信息来验证实例（检查约束是否满足），或告知接口收集用户输入，以确保约束得到满足。
验证行为和关键字在 单独的文档 [json-schema-validation] 中进行了指定。
JSON 架构可以对实例进行注释，只要该实例通过包含注释的架构对象及其所有父架构对象进行验证。
详细的注释行为以及一小部分基本注释关键字在 验证规范 [json-schema-validation] 中进行了定义。
JSON 超级架构描述了 JSON 文档的超文本结构。这包括从实例到其他资源的链接关系、对实例作为多媒体数据的解释以及使用 API 所需的提交数据。
超级架构行为和关键字在 单独的文档 [json-hyper-schema] 中进行了指定。
JSON 文档是由 application/json 媒体类型描述的信息资源（一系列字节）。
在 JSON 架构中，由于它定义的数据模型，术语“JSON 文档”、“JSON 文本”和“JSON 值”可以互换使用。
JSON 架构仅在 JSON 文档上定义。但是，任何可以根据 JSON 架构数据模型解析成或处理成 JSON 文档或内存结构的文档或内存结构都可以根据 JSON 架构进行解释，包括 CBOR [RFC7049] 等媒体类型。
将架构应用于的 JSON 文档称为“实例”。
JSON 架构根据数据模型解释文档。根据此数据模型解释的 JSON 值称为“实例”。
实例具有六种基本类型之一，以及取决于类型的各种可能的值
因此，空白和格式问题（包括在数据模型中相等的数字的不同词法表示）不在 JSON 架构的范围内。希望处理这种词法表示差异的 JSON 架构 词汇表 [vocabulary] 应定义关键字来精确地解释数据模型内的格式化字符串，而不是依赖于原始 JSON 表示的 Unicode 字符可用。
由于对象不能包含两个具有相同键的属性，因此对于尝试在单个对象中定义两个具有相同键（“string” 产生式）的属性（“member” 产生式）的 JSON 文档，其行为未定义。
请注意，JSON 架构词汇表可以自由定义自己的扩展类型系统。这与这里定义的核心数据模型类型不同。例如，“integer” 是词汇表可以定义为关键字值的合理类型，但数据模型没有区分整数和其他数字。
JSON 架构旨在与 "application/json" 文档以及使用 "+json" 结构化语法后缀的媒体类型完全兼容。
每个媒体类型都定义了某些与架构协作时有用的功能，即媒体类型参数和 URI 片段标识符语法和语义。这些功能分别在内容协商和计算实例内特定位置的 URI 时很有用。
本规范定义了媒体类型 "application/schema-instance+json"，以便实例作者能够充分利用参数和片段标识符实现这些目的。
当且仅当两个 JSON 实例根据数据模型具有相同的类型和相同的值时，它们才被认为是相等的。具体来说，这意味着
此定义意味着数组的长度必须相同，对象的成员数必须相同，对象中的属性是无序的，无法定义两个具有相同键的属性，并且仅仅的格式差异（缩进、逗号的位置、尾随零）无关紧要。
JSON 架构文档（简称架构）是一个用于描述实例的 JSON 文档。架构本身被解释为实例，但应始终使用媒体类型 "application/schema+json" 而不是 "application/schema-instance+json"。定义媒体类型 "application/schema+json" 的目的是提供媒体类型参数和片段标识符语法和语义的超集，这些语法和语义由 "application/schema-instance+json" 提供。
JSON Schema 必须是对象或布尔值。
应用于实例的对象属性称为关键字或模式关键字。 广义地说，关键字属于以下两类之一或两者。
关键字可能属于任何一类或两类。 扩展关键字是指在此文档及其配套文档之外定义的关键字，这些关键字可以自由定义其他行为。
布尔模式值“true”和“false”是微不足道的断言，无论实例值如何，始终会返回自身。 例如，在验证词汇表方面，布尔模式等效于以下行为
JSON Schema 可以包含不是模式关键字的属性。 应忽略未知关键字。
空模式是没有任何属性或只有未知属性的 JSON Schema。
JSON Schema 词汇表是为特定目的定义的一组关键字。 词汇表指定其关键字的含义为断言、注释和/或任何词汇表定义的关键字类别。 此文档的两个配套标准分别定义了一个词汇表：一个用于实例验证，另一个用于超媒体注释。 词汇表是 JSON Schema 媒体类型中扩展性的主要机制。
词汇表可以由任何实体定义。 如果词汇表旨在广泛使用，并且可能与其他词汇表结合使用，则词汇表作者应注意避免关键字名称冲突。 JSON Schema 没有提供任何正式的命名空间系统，但也对关键字名称没有限制，允许使用任意数量的命名空间方法。
词汇表可以相互建立，例如通过定义其关键字相对于另一个词汇表中关键字的行为，或通过使用来自另一个词汇表的关键字，但使用受限或扩展的允许值集。 并非所有此类词汇表重用都会导致一个与构建它的词汇表兼容的新词汇表。 词汇表作者应清楚地记录预期何种级别的兼容性（如果有）。
描述模式本身的模式称为元模式。 元模式用于验证 JSON 模式并指定它使用的词汇表。 [CREF1]当前，每个模式只能指定一个元模式，这意味着为了使用多个词汇表，必须编写包含所有词汇表的元模式。 超模式元模式就是一个例子，因为它包含验证词汇表和超媒体词汇表。
根模式是指包含所讨论的整个 JSON 文档的模式。
一些关键字本身就采用模式，允许 JSON 模式嵌套
{
"title": "root",
"items": {
"title": "array item"
}
}
在本示例文档中，标题为“数组项”的模式是子模式，标题为“根”的模式是根模式。
与根模式一样，子模式也是对象或布尔值。
根据 [RFC6839] 的第 3.1 节，为任何 +json 媒体类型指定的片段标识符的语法和语义应与“application/json”中指定的相同。 （在发布此文档时，还没有为“application/json”定义片段标识语法。）
此外，“application/schema+json”媒体类型支持两种片段标识符结构：普通名称和 JSON 指针。“application/schema-instance+json”媒体类型支持一种片段标识符结构：JSON 指针。
JSON 指针作为 URI 片段标识符的使用在 RFC 6901 [RFC6901] 中进行了描述。 对于支持两种片段标识符语法的“application/schema+json”，匹配 JSON 指针语法的片段标识符（包括空字符串）必须解释为 JSON 指针片段标识符。
根据 W3C 的 片段标识符最佳实践 [W3C.WD-fragid-best-practices-20121025]，“application/schema+json”中的普通名称片段标识符保留用于引用本地命名的模式。 所有与 JSON 指针语法不匹配的片段标识符必须解释为普通名称片段标识符。
在“application/schema+json”文档中定义和引用普通名称片段标识符在 "$id" 关键字 [id-keyword] 部分进行了指定。
实例可以是 JSON [RFC7159] 中定义的任何有效 JSON 值。 JSON Schema 对类型没有限制：JSON Schema 可以描述任何 JSON 值，包括例如 null。
JSON Schema 与编程语言无关，并支持数据模型中描述的全部值范围。 但是，请注意，某些语言和 JSON 解析器可能无法在内存中表示 JSON 可描述的全部值范围。
某些编程语言和解析器对浮点数使用不同的内部表示，而对整数使用不同的内部表示。
为确保一致性，整数 JSON 数字不应使用小数部分进行编码。
实现可以为 JSON Schema 定义其他关键字。 除非明确同意，否则模式作者不应期望同行实现支持这些额外的关键字。 实现应忽略不支持的关键字。
鼓励 JSON Schema 扩展的作者编写自己的元模式，这些元模式使用“allOf”扩展现有元模式。 应使用“$schema”关键字引用此扩展的元模式，以允许工具遵循正确行为。
请注意，元模式的递归性质要求在扩展的元模式中重新定义递归关键字，如 JSON 超模式元模式所示。
“$schema”关键字既用作 JSON Schema 版本标识符，也用作资源的位置，该资源本身是 JSON Schema，用于描述为此特定版本编写的任何模式。
此关键字的值必须是 URI [RFC3986]（包含方案），并且此 URI 必须是规范化的。 当前模式必须根据此 URI 标识的元模式进行验证。
如果此 URI 标识一个可检索的资源，则该资源应该是“application/schema+json”媒体类型。
应在根模式中使用“$schema”关键字。 它不能出现在子模式中。
此属性的值在其他文档和其他方中定义。 JSON Schema 实现应根据合理性，实现对当前和先前已发布的 JSON Schema 词汇表草案的支持。
为了区分庞大生态系统中的模式，模式通过 URI [RFC3986] 标识，并且可以通过指定其 URI 来嵌入对其他模式的引用。
RFC 3986 第 5.1 节 [RFC3986] 定义了如何确定文档的默认基准 URI。
信息性地，模式的初始基准 URI 是发现该模式的 URI，或者如果不知道则是一个合适的替代 URI。
“$id”关键字定义了模式的 URI 以及模式中其他 URI 引用解析的基准 URI。 子模式的“$id”是根据其父模式的基准 URI 解析的。 如果没有父模式设置了显式的基准，则基准 URI 是整个文档的基准 URI，如 RFC 3986 第 5 节 [RFC3986] 中所述。
如果存在，则此关键字的值必须是字符串，并且必须表示有效的 URI 引用 [RFC3986]。 此值应规范化，不应为空片段 <#> 或空字符串 <>。
JSON Schema 文档的根模式应包含一个“$id”关键字，该关键字带有 绝对 URI [RFC3986]（包含方案，但没有片段），或者带有空片段的此绝对 URI。
当“$id”设置基准 URI 时，可以使用从该位置开始的 JSON 指针片段来标识包含该“$id”及其所有子模式的对象。 即使子模式进一步更改基准 URI，也是如此。 因此，单个子模式可以通过多个 URI 访问，每个 URI 都由子模式或父模式中声明的基准 URI 以及标识从声明基准的模式对象到要标识的子模式的路径的 JSON 指针片段组成。 本节 8.2.4 中显示了此类示例。
使用 JSON 指针片段需要了解模式的结构。 在编写旨在提供可重用模式的模式文档时，最好使用不与任何特定结构位置绑定的普通名称片段。 这允许子模式重新定位，而无需更新 JSON 指针引用。
为了指定这样的子模式标识符，“$id”关键字被设置为具有普通名称片段（而不是 JSON 指针片段）的 URI 引用。 此值必须以指定片段（“#”）的数字符号开头，然后是一个字母（[A-Za-z]），然后是任意数量的字母、数字（[0-9]）、连字符（“-”）、下划线（“_”）、冒号（“:”）或句点（“.”）。
使用“$id”中不是空白或不遵循普通名称语法的片段的效果是未定义的。 [CREF3]如何解释包含具有其他组件的片段的“$id”URI 引用？ 有两种情况：当其他组件与当前基准 URI 匹配时以及当它们更改基准 URI 时。
考虑以下模式，它显示了“$id”用于标识根模式、更改子模式的基准 URI 以及为子模式分配普通名称片段。
{
"$id": "http://example.com/root.json",
"definitions": {
"A": { "$id": "#foo" },
"B": {
"$id": "other.json",
"definitions": {
"X": { "$id": "#bar" },
"Y": { "$id": "t/inner.json" }
}
},
"C": {
"$id": "urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f"
}
}
}
以下 URI 编码 JSON 指针 [RFC6901]（相对于根模式）处的模式具有以下基准 URI，并且可以根据第 5 节以上列出的任何 URI 标识
“$ref” 关键字用于引用 Schema，并提供通过自引用验证递归结构的能力。
具有 “$ref” 属性的 Schema 对象 MUST 被解释为 “$ref” 引用。 “$ref” 属性的值 MUST 为 URI 引用。相对于当前 URI 基址解析，它标识要使用的 Schema 的 URI。 “$ref” 对象中的所有其他属性 MUST 被忽略。
URI 不是网络定位器，而只是一个标识符。如果它是一个可通过网络寻址的 URL，则 Schema 无需从地址下载，实现 SHOULD NOT 假设它们在遇到可通过网络寻址的 URI 时应该执行网络操作。
Schema MUST NOT 对 Schema 陷入无限循环。例如，如果两个 Schema “#alice” 和 “#bob” 都具有指向彼此的 “allOf” 属性，则一个简单的验证器可能会陷入无限递归循环中，试图验证实例。Schema SHOULD NOT 使用类似的无限递归嵌套；此行为未定义。
使用 URI 来标识远程 Schema 并不一定意味着任何内容都会被下载，而是 JSON Schema 实现 SHOULD 提前了解它们将使用的 Schema 以及标识它们的 URI。
当 Schema 被下载时，例如由一个不知道在运行时要下载哪些 Schema 的通用用户代理下载时，请参见 超媒体的使用 [超媒体]。
实现 SHOULD 能够将任意 URI 与任意 Schema 相关联，或者根据验证器对 Schema 的信任程度自动将 Schema 的 “$id” 给定的 URI 相关联。这些 URI 和 Schema 可以先于处理实例提供给实现，或者可能在处理 Schema 文档时在其中被注意到，生成如第 8.2.4 节所示的关联。
Schema MAY（并且可能）具有多个 URI，但没有办法让 URI 标识多个 Schema。当多个 Schema 尝试标识为同一个 URI 时，验证器 SHOULD 触发错误条件。
Schema 可以通过赋予它们的任何 URI 来标识，包括 JSON 指针或直接由 “$id” 给定的 URI。在所有情况下，取消引用 “$ref” 引用都涉及首先根据 RFC 3986 [RFC3986] 相对于当前基址 URI 解析其值作为 URI 引用。
如果结果 URI 标识当前文档内的 Schema，或者标识已提供给实现的其他 Schema 文档内的 Schema，则 SHOULD 自动使用该 Schema。
例如，考虑以下 Schema
{
"$id": "http://example.net/root.json",
"items": {
"type": "array",
"items": { "$ref": "#item" }
},
"definitions": {
"single": {
"$id": "#item",
"type": "object",
"additionalProperties": { "$ref": "other.json" }
}
}
}
当实现遇到 <#/definitions/single> Schema 时，它将 “$id” URI 引用解析为当前基址 URI 以形成 <http://example.net/root.json#item>。
当实现随后查看 <#/items> Schema 内部时，它会遇到 <#item> 引用，并将此解析为 <http://example.net/root.json#item>，它已经看到此引用在此文档中定义，因此可以自动使用它。
当实现遇到对 “other.json” 的引用时，它会将此解析为 <http://example.net/other.json>，该引用未在此文档中定义。如果具有该标识符的 Schema 以其他方式提供给实现，它也可以自动使用。 [CREF4]当引用的 Schema 未知时，实现应该怎么做？在哪些情况下允许自动网络取消引用？同源策略？用户可配置选项？在由超 Schema 描述的不断发展的 API 的情况下，预计新的 Schema 会动态添加到系统中，因此绝对要求预先加载 Schema 文档是不可行的。
此关键字保留用于 Schema 作者对 Schema 阅读者或维护者的注释。此关键字的值 MUST 为字符串。实现 MUST NOT 将此字符串呈现给最终用户。用于编辑 Schema 的工具 SHOULD 支持显示和编辑此关键字。此关键字的值 MAY 用于针对开发人员的调试或错误输出，这些开发人员使用 Schema。Schema 词汇 SHOULD 允许任何包含词汇关键字的对象中的 “$comment”。除非词汇明确禁止，否则实现 MAY 假设允许 “$comment”。词汇 MUST NOT 指定除本规范中描述的之外的 “$comment” 的任何效果。将其他媒体类型或编程语言翻译成 application/schema+json 和从 application/schema+json 翻译的工具 MAY 选择将该媒体类型或编程语言的本机注释转换为 “$comment” 值或从 “$comment” 值转换。当存在本机注释和 “$comment” 属性时，这种翻译的行为取决于实现。实现 SHOULD 将 “$comment” 与未知扩展关键字相同对待。它们 MAY 在处理过程中的任何时候剥离 “$comment” 值。特别是，这允许在部署 Schema 的大小成为问题时缩短 Schema。实现 MUST NOT 根据 “$comment” 属性的存在、不存在或内容采取任何其他操作。
JSON 已被 HTTP 服务器广泛用于自动化 API 和机器人。本节描述了在与支持媒体类型和 Web 链接 [RFC8288] 的协议一起使用时，如何以更 RESTful 的方式增强对 JSON 文档的处理。
RECOMMENDED 由 Schema 描述的实例使用链接关系 “describedby” 提供指向可下载 JSON Schema 的链接，如 链接数据协议 1.0，第 8.1 节 [W3C.REC-ldp-20150226] 中定义。
在 HTTP 中，此类链接可以使用 链接标头 [RFC8288] 附加到任何响应。此类标头的示例将是
Link: <http://example.com/my-hyper-schema#>; rel="describedby"
媒体类型 MAY 允许使用 “schema” 媒体类型参数，该参数使 HTTP 服务器能够基于 Schema 执行内容类型协商。媒体类型参数 MUST 为一个空格分隔的 URI 列表（即相对引用无效）。
当使用媒体类型 application/schema-instance+json 时，MUST 提供 “schema” 参数。
Schema URI 是不透明的，SHOULD NOT 自动取消引用。如果实现不理解提供的 Schema 的语义，实现可以改为遵循 “describedby” 链接（如果有），这些链接可能提供有关如何处理 Schema 的信息。由于 “schema” 不一定指向网络位置，因此 “describedby” 关系用于链接到可下载的 Schema。但是，为了简化，Schema 作者应尽可能使这些 URI 指向同一资源。
在 HTTP 中，媒体类型参数将在 Content-Type 标头内发送
Content-Type: application/json;
schema="http://example.com/my-hyper-schema#"
多个 Schema 用空格分隔
Content-Type: application/json;
schema="http://example.com/alice http://example.com/bob"
[CREF5]本段假设我们可以注册一个 “schema” 链接关系。现在我们是否应该改为指定类似于 “tag:json-schema.org,2017:schema” 的内容？ HTTP 也可以在链接中发送 “schema”，尽管如果这完全替换了媒体类型参数，则可能会影响媒体类型语义和内容类型协商
Link: </alice>;rel="schema", </bob>;rel="schema"
当用于通过网络的超媒体系统时，HTTP [RFC7231] 通常是用于分发 Schema 的首选协议。如果行为不当的客户端比必要时更频繁地从网络上拉取 Schema，而不是有可能长时间缓存 Schema，则行为不当的客户端可能会给服务器维护者带来问题。
HTTP 服务器 SHOULD 在 JSON Schema 上设置长期缓存标头。HTTP 客户端 SHOULD 遵守缓存标头，并且在它们的有效期内不重新请求文档。分布式系统 SHOULD 利用共享缓存和/或缓存代理。
User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
客户端 SHOULD 设置或添加特定于 JSON Schema 实现或软件产品的 User-Agent 标头。由于符号按重要性降序排列，因此 JSON Schema 库名称/版本应在更通用的 HTTP 库名称（如果有）之前。例如
客户端 SHOULD 能够使用 “From” 标头发出请求，以便服务器运营商可以联系可能行为不当的脚本的所有者。
Schema 和实例都是 JSON 值。因此，RFC 7159 [RFC7159] 中定义的所有安全注意事项都适用。
实例和 Schema 通常由不受信任的第三方编写，并在公共 Internet 服务器上部署。验证器应注意，解析和根据 Schema 进行验证不会消耗过多的系统资源。验证器 MUST NOT 陷入无限循环。
服务器 MUST 确保恶意方无法通过上传具有现有或非常相似的 “$id” 的 Schema 来更改现有 Schema 的功能。
各个 JSON Schema 词汇可能会也有自己的安全注意事项。请参阅相应的规范以获取更多信息。
Schema 作者应注意 “$comment” 的内容，因为恶意实现可能会违反规范将其显示给最终用户，或者如果预期此行为，则未能将其剥离。
恶意 Schema 作者可以在 “$comment” 中放置可执行代码或其他危险材料。实现 MUST NOT 解析或根据 “$comment” 内容采取其他操作。
JSON Schema 的建议 MIME 媒体类型定义如下
需要 JSON Schema 特定媒体类型的 JSON Schema 实例的建议 MIME 媒体类型定义如下
| [RFC2119] | Bradner, S.，"用于在 RFC 中指示需求级别的关键词"，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997 年 3 月。 |
| [RFC3986] | Berners-Lee, T.，Fielding, R. 和 L. Masinter，"统一资源标识符 (URI)：通用语法"，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005 年 1 月。 |
| [RFC6839] | Hansen, T. 和 A. Melnikov，"其他媒体类型结构化语法后缀"，RFC 6839，DOI 10.17487/RFC6839，2013 年 1 月。 |
| [RFC6901] | Bryan, P.，Zyp, K. 和 M. Nottingham，"JavaScript 对象表示法 (JSON) 指针"，RFC 6901，DOI 10.17487/RFC6901，2013 年 4 月。 |
| [RFC7159] | Bray, T.，"JavaScript 对象表示法 (JSON) 数据交换格式"，RFC 7159，DOI 10.17487/RFC7159，2014 年 3 月。 |
| [W3C.REC-ldp-20150226] | Speicher, S.，Arwe, J. 和 A. Malhotra，"链接数据平台 1.0"，万维网联盟建议 REC-ldp-20150226，2015 年 2 月。 |
| [RFC7049] | Bormann, C. 和 P. Hoffman，"简洁二进制对象表示 (CBOR)"，RFC 7049，DOI 10.17487/RFC7049，2013 年 10 月。 |
| [RFC7231] | Fielding, R. 和 J. Reschke，"超文本传输协议 (HTTP/1.1)：语义和内容"，RFC 7231，DOI 10.17487/RFC7231，2014 年 6 月。 |
| [RFC8288] | Nottingham, M.，"Web 链接"，RFC 8288，DOI 10.17487/RFC8288，2017 年 10 月。 |
| [W3C.WD-fragid-best-practices-20121025] | Tennison, J.，"片段标识符和媒体类型定义的最佳实践"，万维网联盟 LastCall WD-fragid-best-practices-20121025，2012 年 10 月。 |
| [json-schema-validation] | Wright, A.，Andrews, H. 和 G. Luff，"JSON Schema 验证：用于 JSON 结构验证的词汇表"，互联网草案 draft-handrews-json-schema-validation-01，2017 年 11 月。 |
| [json-hyper-schema] | Andrews, H. 和 A. Wright，"JSON 超级 Schema：用于 JSON 超媒体注释的词汇表"，互联网草案 draft-handrews-json-schema-hyperschema-01，2017 年 11 月。 |
感谢 Gary Court、Francis Galiegue、Kris Zyp 和 Geraint Luff 对 JSON Schema 初稿的贡献。
感谢 Jason Desrosiers、Daniel Perrett、Erik Wilde、Ben Hutton、Evgeny Poberezkin、Brad Bowman、Gowry Sankar、Donald Pipowitch 和 Dave Finlay 对文档的提交和修补。