5

我对 json 很陌生。在定义我的 RESTful API 结果的格式（即 JSON）时，我觉得将它记录为我自己的JSON 模式会更容易。在写一篇的时候，我有几个问题：

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

[忽略这一行，这是为了使格式适用于以下 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 类型，这是不可能的，但它似乎是一个基本的用例！

4

4 回答 4

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

你总是可以通过验证你的模式来测试一下，看看你是否犯了任何错误。

于 2013-09-17T16:07:29.257 回答
3

在撰写本文时，JSON Schema 规范的当前版本是draft-v4，其中明确指定date-time了string实例的格式并且在实践中非常有用。

date到目前为止还没有定义更简单的格式，但您可以轻松地将对象的属性定义为类型string，然后在其上应用format 模式验证（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}$"
        }
    }
}
于 2014-05-23T08:56:38.200 回答
2

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

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

于 2012-07-26T15:22:54.260 回答
1

该规范似乎建议您可以：

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

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

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

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

于 2012-06-26T23:09:38.227 回答