JSON Schema规范 json schema java

转载

mob6454cc67554d 2024-03-01 15:57:28

文章标签 JSON Schema规范 json JSON 正则表达式字符串 文章分类 机器学习人工智能

JSON Schema 简介

一、什么是 Schema

JSON 代表“JavaScript Object Notation”，一种简单的数据交换格式。它最初是作为万维网的符号。由于 JavaScript 存在于大多数 Web 浏览器中，并且 JSON 基于 JavaScript，因此很容易支持。然而，它已被证明足够有用且足够简单，以至于它现在被用于许多其他不涉及网上冲浪的环境中。

JSON Schema 是用于验证 JSON 数据结构的强大工具，Schema可以理解为模式或者规则。然而，通过阅读它的规范来学习如何使用就像通过查看汽车的设计图来学习驾驶汽车。如果您只想买些杂货，那你是不需要知道电动机是如何组合在一起的。

从本质上讲，JSON 建立在以下数据结构上：

对象（object）

{ “key1”: “value1”, “key2”: “value2” }

数组（array）

[ “first”, “second”, “third” ]

数字（integer/number）

42
3.1415926

字符串（string）

“This is a string”

布尔值（boolean）

true / false

null

null

Json schema 示例

{
  "type": "object",
  "properties": {
    "first_name": { "type": "string" },
    "last_name": { "type": "string" },
    "birthday": { "type": "string", "format": "date" },
    "address": {
      "type": "object",
      "properties": {
        "street_address": { "type": "string" },
        "city": { "type": "string" },
        "state": { "type": "string" },
        "country": { "type" : "string" }
      }
    }
  }
}

按照上面的模式，验证失败的 Json 串:

{
  "name": "George Washington",
  "birthday": "February 22, 1732",
  "address": "Mount Vernon, Virginia, United States"
}

按照上面的模式，验证成功的 Json 串:

{
  "first_name": "George",
  "last_name": "Washington",
  "birthday": "1732-02-22",
  "address": {
    "street_address": "3200 Mount Vernon Memorial Highway",
    "city": "Mount Vernon",
    "state": "Virginia",
    "country": "United States"
  }
}

我们注意到 JSON Schema 本身是用 JSON 编写的。它是数据本身，而不是计算机程序。它只是一种用于“描述其他数据结构”的声明性格式。这既是它的优点也是它的缺点（它与其他类似的模式语言共享）。简明地描述数据的表面结构并根据它自动验证数据很容易。但是，由于 JSON Schema 不能包含任意代码，因此在表达数据元素之间的关系上有所限制。因此，用于足够复杂的数据格式的任何“验证工具”都可能有两个验证阶段：一个在模式（或结构）级别，一个在语义级别。后一种检查可能需要使用更通用的编程语言来实现。

特定Draft注释

JSON Schema 标准已经过多次修订或“ Draft”。当前版本是 Draft 7，但 Draft 4 仍然被广泛使用。

编写该文本是为了鼓励使用Draft 7 并优先考虑最新的约定和功能，但在与早期版本不同的地方，这些差异在特殊标注中突出显示。如果您只想针对 Draft 7，您可以放心地忽略这些部分。

Draft 7 中的新内容

Draft特定信息
Draft 4
这里将记录任何与旧版本有关内容。

二、基础预览

1、入门：Hello, World!

在 JSON 模式中，空对象是一个完全有效的模式，它将接受任何有效的 JSON。

{}

以下都是能接收的：

42 // OK
“I’m a string” // OK
{ “an”: [ “arbitrarily”, “nested” ], “data”: “structure” } // OK

3、类型关键字

在 JSON Schema 中最常见的事情是限制为特定类型，type 关键字就用于此。

例如，在下面，只接受字符串：

{ “type”: “string” }
“I’m a string” // OK
42 // not OK

4、声明一个 JSON 模式

判断 JSON Schema 使用的是哪个draft并不总是那么容易。您可以使用$schema关键字来声明架构写入的 JSON 模式规范是哪个版本。更多信息，请参阅 $schema。

//Draft 7
{ “$schema”: “http://json-schema.org/draft-07/schema#” }
//Draft 4,指最新版本的 JSON Schema，此用法已被弃用，并且需要使用特定版本的 URI。
{ “$schema”: “http://json-schema.org/schema#” }

5、声明唯一标识符

将 $id 属性包含为每个模式的唯一标识符也是最佳实践。现在，只需将其设置为您控制的域中的 URL，例如：

//在draft 4 中，$id 只是 id（没有$符号）
{ “$id”: “http://yourdomain.com/schemas/myschema.json” }

三、JSON Schema 规范

1、数据类型

type关键字是 JSON Schema 的基础。它指定 Schema 的数据类型。

JSON Schema 的核心定义了以下基本类型：

string
number
integer
object
array
布尔值
null

在大多数编程语言中都有类似类型，尽管它们可能有不同的名称。在以下示例中，我们接受字符串和数字，但不接受结构化数据类型：

{ "type": ["number", "string"] }
42 // OK
"Life, the universe, and everything" // OK
["Life", "the universe", "and everything"] // not OK

2、字符串（string）

string 类型用于文本字符串。它可能包含 Unicode 字符。

Unicode 字符参考：

{ “type”: “string” }
“This is a string” // OK
42 // not OK

1)、长度

可以使用 minLength 和 maxLength 关键字来限制字符串的长度。对于这两个关键字，该值必须是非负数。

{“type”: “string”, “minLength”: 2, “maxLength”: 3}
“AB” //OK
“ABC” //OK
“ABCD”// not OK

2)、正则表达式

pattern 关键字用于将字符串限制为特定的正则表达式。正则表达式语法是在 JavaScript（特别是ECMA 262 ）中定义的。有关更多信息，请参阅正则表达式。

以下示例匹配一个带有可选区号的简单北美电话号码：

{
“type”: “string”,
“pattern”: “^($[0-9]{3}$)?[0-9]{3}-[0-9]{4}$”
}
“555-1212” // OK
“(888)555-1212” // OK
“(888)555-1212 ext. 532” // not OK
“(800)FLOWERS” // not OK

3)、格式

该 format 关键字允许对常用的某些类型的字符串值进行基本语义验证。这允许限制值超出 JSON 模式中的其他工具，包括正则表达式可以做的。

日期和时间

日期和时间在RFC 3339 第 5.6 节中表示。这是日期格式的子集，也通常称为ISO8601 格式。

"date-time"：日期和时间在一起，例如， 2018-11-13T20:20:39+00:00。
"time":draft7的时间，例如，20:20:39+00:00
"date":draft7的日期，例如，2018-11-13。

电子邮件地址

"email"：Internet 电子邮件地址，请参阅RFC 5322，第 3.4.1 节。
"idn-email"：draft7的新内容Internet 电子邮件地址的国际化形式，请参阅 RFC 6531。

主机名

"hostname": Internet 主机名，请参阅RFC 1034，第 3.1 节。
"idn-hostname"：draft7的中的新内容，国际化 Internet 主机名，请参阅 RFC5890，第 2.3.2.3 节。

IP 地址

"ipv4"：IPv4 地址，根据RFC 2673 第 3.2 节中定义的点分四线 ABNF 语法。
"ipv6"：IPv6 地址，如RFC 2373 第 2.2 节中所定义。

资源标识符

"uri"：根据RFC3986 的通用资源标识符 (URI) 。
"uri-reference"：draft7 6 中的新增内容，一个 URI 引用（URI 或相对引用），根据RFC3986 第 4.1 节。
"iri"：draft 7 中的新内容，根据RFC3987，“uri”的国际化等价物。
"iri-reference"：draft7中的新内容，根据RFC3987，“uri-reference”的国际化等价物

如果模式中的值能够与特定的源路径（例如来自网页的链接）相关联，那么使用"uri-reference"(or "iri-reference") 而不是"uri"(or "iri")通常是更好的做法。"uri"只应在路径必须是绝对路径时使用。

draft 4 只包括"uri"，不包括"uri-reference"。因此，是否"uri"应该接受相对路径存在一些歧义。

URI 模板

"uri-template"：draft 6 中的新增内容，一个 URI 模板（任何级别）根据 RFC6570。如果您还不知道 URI 模板是什么，您可能不需要这个值。

JSON 指针

"json-pointer"：draft6 中的新内容，一个 JSON 指针，根据RFC6901。在Structuring a complex schema 中有更多关于在 JSON Schema 中使用 JSON Pointer 的讨论。请注意，仅当整个字符串仅包含 JSON 指针内容时才应使用此方法，例如 /foo/bar. JSON 指针 URI 片段，例如#/foo/bar/应该使用 "uri-reference".
"relative-json-pointer"：draft7 中的新内容，一个相对 JSON 指针。

正则表达式

"regex"：draft7中的新内容，正则表达式，根据ECMA 262 应有效。

请注意，在实践中，JSON 模式验证器只需要接受本文档其他地方描述的正则表达式的安全子集。

正则表达式语法描述：

单个 unicode 字符（下面的特殊字符除外）与其自身匹配。
.: 匹配除换行符以外的任何字符。（请注意，换行符的构成在某种程度上取决于您的平台和语言环境）。
^: 只匹配字符串的开头。
$: 仅在字符串末尾匹配。
(...): 将一系列正则表达式组合成一个正则表达式。
|: 匹配|符号之前或之后的正则表达式。
[abc]: 匹配方括号内的任何字符。
[a-z]: 匹配字符范围。
[^abc]: 匹配任何_未_列出的字符。
[^a-z]: 匹配范围外的任何字符。
+: 匹配前面正则表达式的一个或多个重复项。
*: 匹配前面正则表达式的零次或多次重复。
?: 匹配前面正则表达式的零次或一次重复。
+?, *?, ??: *, +, 和?限定符都是贪婪的；它们匹配尽可能多的文本。有时不需要这种行为，您希望匹配尽可能少的字符。
(?!x), (?=x):积极或消极地向前查找。

exp1(?!exp2)：查找后面不是 exp2 的 exp1
exp1(?=exp2)：查找后面是 exp2 的 exp1

{x}: 完全x匹配前面的正则表达式。
{x,y}: 匹配至少x和最多y出现的前面的正则表达式。
{x,}: 匹配x前面的正则表达式中出现的一个或多个。
{x}?, {x,y}?, {x,}?: 上述表达式的懒惰版本。

3、数字类型（integer/number）

JSON Schema 中有两种数字类型：integer 和 number。它们共享相同的验证关键字。

注意：JSON 没有表示复数的标准方法，因此无法在 JSON Schema 中测试它们。

1）、integer

integer 类型用于整数。JSON 没有针对整数和浮点值的不同类型。因此，有无小数点并不足以区分整数和非整数。例如，1和1.0是在 JSON 中表示相同值的两种方式。无论使用哪种表示形式，JSON 模式都将该值视为整数。

{ “type”: “integer” }
 42 // OK-1 // OK
1.0 // OK，小数部分为零的数字被视为整数
3.1415926 // not OK，浮点数被拒绝
“42” // not OK，作为字符串的数字被拒绝

2)、number

该 number 类型用于任何数字类型，整数或浮点数。

{ “type”: “number” }
 42 // OK-1 // OK
5.0 // OK，简单的浮点数
2.99792458e8 // OK，指数符号也有效
“42” // not OK，作为字符串的数字被拒绝

3)、倍数

使用multipleOf关键字将数字限制为给定数字的倍数。它可以设置为任何正数。

{
 “type”: “number”,
 “multipleOf” : 10
 }0 // OK
 10 // OK
 20 // OK
 23 // not OK，不是 10 的倍数

4）、范围

数字的范围是使用 minimum 和 maximum 关键字的组合指定的（或 exclusiveMinimum 和 exclusiveMaximum 用于表示排他范围）。

如果 x 是要验证的值，则以下必须成立：

x ≥ minimum
x > exclusiveMinimum
x ≤ maximum
x < exclusiveMaximum

虽然您可以同时指定minimum和exclusiveMinimum或同时指定maximum和exclusiveMaximum，但这样做没有意义。

{
 “type”: “number”,
 “minimum”: 0,
 “exclusiveMaximum”: 100
 }-1 // not OK，小于0
 0 // OK
 10 // OK
 99 // OK
 100 // not OK
 101 // not OK

Draft 4

在 JSON Schema draft4中，exclusiveMinimum和exclusiveMaximum工作方式不同。它们是布尔值，指示是否 minimum和maximum不包括该值。例如：

如果 exclusiveMinimum 是 false，x ≥ minimum。
如果 exclusiveMinimum 是 true, x > minimum。

使用旧Draft 4 约定的示例

{
 “type”: “number”,
 “minimum”: 0,
 “maximum”: 100,
 “exclusiveMaximum”: true
 }-1 // not OK，小于0
 0 // OK
 10 // OK
 99 // OK
 100 // not OK
 101 // not OK

4、对象（object）

对象是 JSON 中的映射类型。他们将“键”映射到“值”。在 JSON 中，“键”必须始终是字符串。每对中的第二个被称为“值”。

{ “type”: “object” }
{// OK
 “key”: “value”,
 “another_key”: “another_value”
 }{// OK
 “Sun”: 1.9891e30,
 “Jupiter”: 1.8986e27,
 “Saturn”: 5.6846e26,
 “Neptune”: 10.243e25,
 “Uranus”: 8.6810e25,
 “Earth”: 5.9736e24,
 “Venus”: 4.8685e24,
 “Mars”: 6.4185e23,
 “Mercury”: 3.3022e23,
 “Moon”: 7.349e22,
 “Pluto”: 1.25e22
 }{// not OK，使用非字符串作为键是无效的 JSON
 0.01: “cm”,
 1: “m”,
 1000: “km”
 }“Not an object” // not OK，使用非字符串作为键是无效的 JSON
[“An”, “array”, “not”, “an”, “object”] // not OK

1)、属性

对象的属性（键值对）是使用 properties 关键字定义的。properties 的值是一个对象，其中每个键是属性的名称，每个值是用于验证该属性的模式。此 properties 关键字将忽略与关键字中的任何属性名称不匹配的任何属性。

我们要为由数字、街道名称和街道类型组成的地址定义一个简单的模式：

{
 “type”: “object”,
 “properties”: {
 “number”: { “type”: “number” },
 “street_name”: { “type”: “string” },
 “street_type”: { “enum”: [“Street”, “Avenue”, “Boulevard”] }
 }
 }// OK
 { “number”: 1600, “street_name”: “Pennsylvania”, “street_type”: “Avenue” }// not OK，提供的号码类型错误，则无效
 { “number”: “1600”, “street_name”: “Pennsylvania”, “street_type”: “Avenue” }// OK，默认情况下，省略属性是有效的。请参阅必需属性。
 { “number”: 1600, “street_name”: “Pennsylvania” }// OK，通过扩展，即使是空对象也是有效的
 { }// OK，默认情况下，提供附加属性是有效的：
 { “number”: 1600, “street_name”: “Pennsylvania”, “street_type”: “Avenue”, “direction”: “NW” }

2)、模式属性

给定一种特定类型的属性名称，该值应该与特定模式相匹配。这就是 patternProperties 起作用的地方：它将正则表达式映射到模式。如果属性名称与给定的正则表达式匹配，则属性值必须针对相应的架构进行验证。

在此示例中，名称以前缀开头的任何属性都 S_ 必须是字符串，并且任何具有前缀的属性都 I_ 必须是整数。任何与任一正则表达式都不匹配的属性将被忽略。

{
 “type”: “object”,
 “patternProperties”: {
 “^S_”: { “type”: “string” },
 “^I_”: { “type”: “integer” }
 }
 }// OK
 { “S_25”: “This is a string” }// OK
 { “I_0”: 42 }// not OK，如果名称以 开头S_，则必须是字符串
 { “S_0”: 42 }// not OK，如果名称以 开头I_，则必须是整数
 { “I_42”: “This is a string” }// OK这是一个不匹配任何正则表达式的键
 { “keyword”: “value” }

3)、额外属性

additionalProperties 关键字的值是一个模式，将用于验证实例中与 properties 或不匹配的任何属性 patternProperties。将 additionalProperties 设置为false 意味着不允许其他属性。

{
 “type”: “object”,
 “properties”: {
 “number”: { “type”: “number” },
 “street_name”: { “type”: “string” },
 “street_type”: { “enum”: [“Street”, “Avenue”, “Boulevard”] }
 },
 “additionalProperties”: false
 }// OK
 { “number”: 1600, “street_name”: “Pennsylvania”, “street_type”: “Avenue” }// not OK，额外属性“direction”使对象无效
 { “number”: 1600, “street_name”: “Pennsylvania”, “street_type”: “Avenue”, “direction”: “NW” }

使用非布尔模式对实例的其他属性设置更复杂的约束。例如，可以允许额外的属性，但前提是它们都是一个字符串：

{
 “type”: “object”,
 “properties”: {
 “number”: { “type”: “number” },
 “street_name”: { “type”: “string” },
 “street_type”: { “enum”: [“Street”, “Avenue”, “Boulevard”] }
 },
 “additionalProperties”: { “type”: “string” }
 }// OK
 { “number”: 1600, “street_name”: “Pennsylvania”, “street_type”: “Avenue” }// OK，这是有效的，因为附加属性的值是一个字符串
 { “number”: 1600, “street_name”: “Pennsylvania”, “street_type”: “Avenue”, “direction”: “NW” }// not OK，这是无效的，因为附加属性的值不是字符串：
 { “number”: 1600, “street_name”: “Pennsylvania”, “street_type”: “Avenue”, “office_number”: 201 }

additionalProperties 与 properties 和 patternProperties 组合起来使用。在以下示例中，基于 Pattern Properties 中的示例，我们添加了一个 "builtin" 属性，该属性必须是数字，并声明所有其他属性（既不符合 properties 定义，同时不匹配 patternProperties）必须是字符串：

{
 “type”: “object”,
 “properties”: {
 “builtin”: { “type”: “number” }
 },
 “patternProperties”: {
 “^S_”: { “type”: “string” },
 “^I_”: { “type”: “integer” }
 },
 “additionalProperties”: { “type”: “string” }
 }// OK
 { “builtin”: 42 }// OK，这是一个不匹配任何正则表达式的键：
 { “keyword”: “value” }// not OK，额外属性必须是一个字符串：
 { “keyword”: 42 }

4)、必须属性

默认情况下，properties不需要关键字定义的属性。但是，可以使用required关键字提供所需属性的列表。

该 required 关键字采用零个或多个字符串的数组。这些字符串中的每一个都必须是唯一的。

{
 “type”: “object”,
 “properties”: {
 “name”: { “type”: “string” },
 “email”: { “type”: “string” },
 “address”: { “type”: “string” },
 “telephone”: { “type”: “string” }
 },
 “required”: [“name”, “email”]
 }// OK
 {
 “name”: “William Shakespeare”,
 “email”: “bill@stratford-upon-avon.co.uk”
 }// OK，提供额外的属性是可以的，即使是架构中没有定义的属性：
 {
 “name”: “William Shakespeare”,
 “email”: “bill@stratford-upon-avon.co.uk”,
 “address”: “Henley Street, Stratford-upon-Avon, Warwickshire, England”,
 “authorship”: “in question”
 }// not OK，缺少必需的“email”属性会使 JSON 文档无效
 {
 “name”: “William Shakespeare”,
 “address”: “Henley Street, Stratford-upon-Avon, Warwickshire, England”,
 }// not OK，在 JSON 中，具有值的属性null不等同于不存在的属性。这失败，因为null不是“字符串”类型，而是“空”类型
 {
 “name”: “William Shakespeare”,
 “address”: “Henley Street, Stratford-upon-Avon, Warwickshire, England”,
 “email”: null
 }

5)、属性名称

可以根据模式验证属性名称，而不管它们的值。如果您不想强制执行特定属性，但您想确保这些属性的名称遵循特定约定。例如，您可能想要强制所有名称都是有效的 ASCII 标记，以便它们可以用作特定编程语言中的属性。

{
  "type": "object",
  "propertyNames": {
    "pattern": "^[A-Za-z_][A-Za-z0-9_]*$"
  }
}

// OK
{
  "_a_proper_token_001": "value"
}
 // not OK
{
  "001 invalid": "value"
}

由于对象键无论如何必须始终是字符串，因此暗示给定的模式 propertyNames 始终至少为：

{ "type": "string" }

6)、属性数量

可以使用 minProperties 和 maxProperties 关键字来限制对象上的属性数量。这些中的每一个都必须是非负整数。

{
  "type": "object",
  "minProperties": 2,
  "maxProperties": 3
}

{}  // not OK
{ "a": 0 }  // not OK
{ "a": 0, "b": 1 } // OK
{ "a": 0, "b": 1, "c": 2 } // OK
{ "a": 0, "b": 1, "c": 2, "d": 3 }  // not OK

5、数组（array）

数组用于有序元素。在 JSON 中，数组中的每个元素可能是不同的类型。

{ "type": "array" }

[1, 2, 3, 4, 5] // OK
[3, "different", { "types" : "of values" }] // OK
{"Not": "an array"}  // not OK

1）、元素

JSON 中数组的使用一般有两种方式：

**列表验证：**任意长度的序列，其中每个元素都匹配相同的模式。
**元组验证：**一个固定长度的序列，其中每个元素可能有不同的模式。在这种用法中，每个元素的索引（或位置）对于如何解释值是有意义的。

2）、列表验证

列表验证对于任意长度的数组很有用，其中每个元素都匹配相同的模式。对于这种类型的数组，将 items 关键字设置为单个模式，将用于验证数组中所有元素。

在下面的例子中，我们定义数组中的每一项都是一个数字：

{
  "type": "array",
  "items": {
    "type": "number"
  }
}

[1, 2, 3, 4, 5] // OK
[1, 2, "3", 4, 5]  // not OK，单个“非数字”会导致整个数组无效
[] // OK，空数组始终有效

3）、元组验证

一个固定长度的序列，其中每个元素可能有不同的模式。在这种用法中，每个元素的索引（或位置）对于如何解释值是有意义的。

示例：

{
  "type": "array",
  "items": [
    { "type": "number" },
    { "type": "string" },
    { "enum": ["Street", "Avenue", "Boulevard"] },
    { "enum": ["NW", "NE", "SW", "SE"] }
  ]
}

[1600, "Pennsylvania", "Avenue", "NW"] // OK
[24, "Sussex", "Drive"]  // not OK，“Drive”不是可接受的街道类型之一
["Palais de l'Élysée"]  // not OK，此地址缺少街道号码（这里没懂？）
[10, "Downing", "Street"] // OK，可以不提供所有元素
[1600, "Pennsylvania", "Avenue", "NW", "Washington"] // OK，默认情况下可以在尾部添加其他元素

4）、附加元素

设置 additionalItems 为 false，这具有禁止数组中的额外元素的效果：

{
  "type": "array",
  "items": [
    { "type": "number" },
    { "type": "string" },
    { "enum": ["Street", "Avenue", "Boulevard"] },
    { "enum": ["NW", "NE", "SW", "SE"] }
  ],
  "additionalItems": false
}

[1600, "Pennsylvania", "Avenue", "NW"] // OK
[1600, "Pennsylvania", "Avenue"] // OK，可以不提供所有元素
[1600, "Pennsylvania", "Avenue", "NW", "Washington"]  // not OK，不能提供额外的元素

允许附加元素，只要它们都是字符串：

{
  "type": "array",
  "items": [
    { "type": "number" },
    { "type": "string" },
    { "enum": ["Street", "Avenue", "Boulevard"] },
    { "enum": ["NW", "NE", "SW", "SE"] }
  ],
  "additionalItems": { "type": "string" }
}

[1600, "Pennsylvania", "Avenue", "NW", "Washington"] // OK，额外的字符串元素是可以的
[1600, "Pennsylvania", "Avenue", "NW", 20500]  // not OK，额外的元素不是字符串

Draft 6 中的新内容：虽然 items 模式必须对数组中的每一项都有效，但 contains 模式只需要针对数组中的一项或多项进行验证。

{
   "type": "array",
   "contains": {
     "type": "number"
   }
}

["life", "universe", "everything", 42] // OK，包含一个number元素
["life", "universe", "everything", "forty-two"]  // not OK，不包含number元素
[1, 2, 3, 4, 5] // OK

5）、长度

使用 minItems 和 maxItems 关键字指定数组的长度。每个关键字的值必须是非负数。

{
  "type": "array",
  "minItems": 2,
  "maxItems": 3
}

[]  // not OK，
[1]  // not OK，
[1, 2] // OK
[1, 2, 3] // OK
[1, 2, 3, 4]  // not OK

6）、唯一性

uniqueItems 关键字设置为 true，可以限制数组中的每个元素都是唯一的。

{
  "type": "array",
  "uniqueItems": true
}

[1, 2, 3, 4, 5] // OK
[1, 2, 3, 3, 4]  // not OK
[] // OK空数组总是通过

6、布尔值（boolean）

布尔类型只匹配两个特殊值：true 和 false。请注意，模式不接受_其他约定_为 true 或 false 的值，例如 1 和 0。

{ "type": "boolean" }

true // OK
false // OK
"true"  // not OK
0  // not OK

7、NULL（null）

当一个模式指定 type 为 null时，它只有一个可接受的值：null。

{ "type": "null" }

null // OK
false  // not OK
0  // not OK
""  // not OK

8、通用关键字

1）、注释

title 和 description 关键字必须是字符串，default 关键字指定一个默认值。该值不用于在验证过程中填充缺失值。文档生成器或表单生成器等非验证工具可能会使用此值提示用户如何使用该值。examples 关键字是提供一系列针对模式进行验证的示例的地方。这不用于验证，但可能有助于向读者解释模式的效果和目的。readOnly 表示该值可读不可改,可用于说明一个更改值的PUT请求将得到一个400 Bad Request 的响应。writeOnly 表示该值可已修改但是不可以读,可用于说明可通过 PUT 请求来设置值，但通过 GET 请求来检索该记录时不能获取该值。

deprecated关键字是一个布尔值，表明该关键字应用的实例值不宜使用，并可能在将来被移除。

{
  "title": "Match anything",
  "description": "This is a schema that matches anything.",
  "default": "Default value",
  "examples": [
    "Anything",
    4035
  ],
  "deprecated": true,
  "readOnly": true,
  "writeOnly": false
}

2）、评论

Draft 7 中的新内容 $comment 关键字严格用于向模式添加注释。它的值必须始终是一个字符串。与注解 title、description 和 examples 不同， JSON 模式实现不允许附加任何含义或行为，甚至可以随时剥离它们。因此，它们对于给 JSON 模式的未来编辑者留下笔记很有用，但不宜用于与模式的用户进行交流。

3）、枚举值

enum 关键字用于将值限制为一组固定的值。它必须是一个包含至少一个元素的数组，其中每个元素都是唯一的。

示例：

{
  "enum": ["red", "amber", "green", null, 42]
}

"red" // OK
null // OK
42 // OK
0  // not OK

4）、常量值

Draft 6 中的新内容 const 关键字被用于限制值为一个常量值。

{
  "properties": {
    "country": {
      "const": "United States of America"
    }
  }
}

{ "country": "United States of America" } // OK
{ "country": "Canada" }  // not OK

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。

上一篇：iOS用fiddler抓包没有网络 fiddler抓包ios app

下一篇：android 事件传递过程安卓事件传递机制面试

提问和评论都可以，用心的回复会被更多人看到评论

发布评论

相关文章

官方博客	全部文章	热门标签	班级博客
了解我们	网站地图	意见反馈

鸿蒙开发者社区	51CTO学堂
51CTO	软考资讯