与自定义 json 架构相关的一些问题

Question

我不熟悉 json。在定义我的 RESTful API 结果的格式（即 JSON）时，我觉得将其记录为我自己的 JSON schema 会更容易。在写一篇文章时，我有几个问题：

1. 在我的结果 JSON 中，如何将 URI 指定到它确认的架构？ --edit-- 是否使用$schema 属性？
2. 是否有任何 JSON 模式版本控制的约定/指南？是否有一些我应该/可以在我的模式中定义为属性的属性？我看到 JSON schema itself 没有定义版本，除了它的 URI 指定为键 $schema 的值。
3. 我能否将我的一个 BIG JSON 模式分解为多个较小的模式并将一个包含在另一个中？就像 C++ 中的 #include 一样，然后引用我发送给用户的 JSON 中的多个模式作为结果。
4. 能否为键“type”定义自定义值？例如。我想像这样重用“日期”的定义：

[忽略这一行，这是为了使格式适用于以下 json..]

{
    "date":{
        "type":"object",
        "properties":{
            "month":{
                "type":"integer",
                "minimum":1,
                "maximum":12
            },
            "year":{
                "type":"integer",
                "minimum":0
            }
        }
    },
    "personInfo":{
        "type":"object",
        "properties":{
            "name":{
                "type":"string"
            },
            "dateOfBirth":{
                "type":"date"
            }
        }
    },
    "student":{
        "type":"object",
        "properties":{
            "id":{
                "type":"personInfo"
            },
            "pass_out_year":{
                "type":"date"
            }
        }
    }
}

而不是像这样在多个地方提供“日期”的属性：

{
    "personInfo":{
        "type":"object",
        "properties":{
            "name":{
                "type":"string"
            },
            "dateOfBirth":{
                "type":"object",
                "properties":{
                    "month":{
                        "type":"integer",
                        "minimum":1,
                        "maximum":12
                    },
                    "year":{
                        "type":"integer",
                        "minimum":0
                    }
                }
            }
        }
    },
    "student":{
        "type":"object",
        "properties":{
            "id":{
                "type":"personInfo"
            },
            "pass_out_year":{
                "type":"object",
                "properties":{
                    "month":{
                        "type":"integer",
                        "minimum":1,
                        "maximum":12
                    },
                    "year":{
                        "type":"integer",
                        "minimum":0
                    }
                }
            }
        }
    }
}

根据 5.1 类型 in the spec，这是不可能的，但它似乎是一个基本的用例！

Answer 1

1. 如您所见，$schema 可用于指定其符合的架构。
2. 我实际上是在搜索 JSON Schema 版本控制时发现了这个主题，使用 URI 进行版本控制的想法听起来合乎逻辑。
3. 您可以使用$ref 链接到另一个架构，然后将其拉入。
4. 同样，您可以使用 $ref 和 JSON Pointer 从其他架构导入定义。

您始终可以通过 validating 您的架构来测试，看看您是否犯了任何错误。

Answer 2

在撰写本文时，JSON Schema 规范的当前版本是draft-v4，其中string 实例的格式date-time 是clearly specified，非常有用在实践中。

到目前为止还没有定义更简单的格式date，但您可以轻松地将对象的属性定义为类型string，然后在其上应用formatpattern validation（ECMA 262 正则表达式方言）。

例如：

{
    "$schema": "http://json-schema.org/draft-04/schema",
    "title": "Example Schema"
    "description": "This schema contains only a birth date property"
    "type": "object",
    "required": ["birth_date"],
    "properties": {
        "birth_date": {
            "type": "string",
            "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$"
        }
    }
}

Answer 3

您为什么不按照#5.23 in JSON Schema Draft 03 使用"format" : "date"？

另外，您对出生日期的定义不包含似乎是错误的日期。

Answer 4

规范似乎表明您可以：

其他类型值可以用于自定义目的，...

然后继续讨论最小实现的验证器可能会做什么。

在我看来，你想做的似乎没问题。 将类型引用和类型定义保存在同一个文件中可能有助于您的架构清晰。

我认为您的文件包含 Q 应该在 json 之外处理，例如有一个开发步骤，从合并子文件的脚本/模板（例如 erb 或类似的）生成完整的 json。在我看来，您的服务应该始终提供与该服务完全交互所需的完整 json。如果从客户的角度来看这变得无法管理，则可能是重构和引入其他服务的信号。