【问题标题】:'$id' property usage in JSON SchemaJSON Schema 中的“$id”属性用法
【发布时间】:2017-10-10 16:11:53
【问题描述】:

我正在使用JSON Schema 来验证数据。

我认为使用保留关键字 $id 可能会使我的架构出现错误。此字段的目的是指定另一个平台上属性的 REMOTE ID 是什么。所以它是“原始ID”。

您能否告知 $id 是什么以及我是否犯了严重错误并且此值需要更改。因为在文档中我找到了这个定义:

如果存在,这个关键字的值必须是一个字符串,并且必须代表一个有效的 URI-reference [RFC3986]。这个值应该被规范化,并且不应该是一个空片段 或一个空字符串 。

【问题讨论】:

    标签: json jsonschema json-schema-validator


    【解决方案1】:

    $id 是保留关键字。

    它服务于:

    • 声明架构或子架构的标识符
    • 声明用于解析 $ref URL 的基本 URL

    您可以使用 $id 来识别架构或架构的一部分(子架构),然后您可以使用 $ref 关键字在其他地方重用它。最简单的方法是 $ref 将被替换为具有相应 id 的模式。

    【讨论】:

      【解决方案2】:

      由于 $id 更改了架构的基本 URI,因此同一架构或其任何子架构中的任何 $ref 值都将以不同方式解析。

      例如,如果您的基本 URI 是“https://example.com/thing” 你有这个架构

      {
          "allOf": [
              {"$ref": "foo"},
              {
                  "$id": "stuff/and/nonsense",
                  "allOf": {"$ref": "bar"}
              }
          ]
      }
      

      然后“$ref”到“foo”解析为“https://example.com/foo”。但是“$ref”到“bar”解析为“https://example.com/stuff/and/bar

      因此,无论您出于其他目的在“$id”中添加什么,都可能导致问题,尤其是“$ref”解析。

      【讨论】:

      • 还是这样吗。我记得阅读 id 的行为已更改以避免覆盖基本 uri 的混淆。
      猜你喜欢
      • 1970-01-01
      • 2012-07-28
      • 2017-04-22
      • 2016-02-06
      • 2014-03-01
      • 1970-01-01
      • 2018-03-25
      • 1970-01-01
      • 2020-07-11
      相关资源
      最近更新 更多