我一直在模式中使用readOnly关键字，我刚刚意识到我只是在构建自己的语义。现在我正在清理我的一堆设计，并试图验证我是否按预期使用了这个注释。验证规范是我提出这个问题的基础，但我想了解更多的示例使用场景。
让我举三个例子。在第一个例子中，我的意思是说整个资源都是只读的。任何东西都不可能在任何水平上发生突变。
{
"type": "object",
"readOnly": true,
"properties": {
"name": {
"type": "string",
},
"members": {
"type": "object",
"properties": {
"member1": { "type" : "string" },
"member2": { "type" : "string" }
}
}
}
}
我不认为这太有争议。但最初，我自己的心理模型是，顶级的readOnly意味着你不能用新的资源替换这个资源。服务器会阻止这种情况发生。但内部成员仍然是可变的。因此，我在name子模式和每个成员子模式中添加了readOnly。我认为删除所有这些都是正确的。(我的心理模型可能松散地基于我在JavaScript中解释常量变量的方式。如果我的常量变量是一个对象，我不能更改变量的值，但我可以改变它的成员，甚至向它添加成员。(
在第二个示例中，我将readOnly完全排除在模式之外。因此，将其视为资源中任何东西都是可变的并不太有争议。
{
"type": "object",
"properties": {
"name": {
"type": "string",
},
"members": {
"type": "object",
"properties": {
"member1": { "type" : "string" },
"member2": { "type" : "string" }
}
}
}
}
在第三个例子中，我想混合和匹配
{
"type": "object",
"properties": {
"name": {
"type": "string",
"readOnly": true
},
"members": {
"type": "object",
"properties": {
"member1": { "type" : "string", "readOnly": true },
"member2": { "type" : "string", "readOnly": true },
"member3": { "type" : "string"},
"member4": { "type" : "string"}
}
}
}
}
在本例中，名称member1和member2是不可变的。成员3和成员4可以被修饰。
所以问题是，我对readOnly的解释有什么不对吗？
链接的规范为readOnly定义了以下内容。。。
如果"readOnly"；具有布尔值true，则表示该值实例的完全由拥有权限管理，并且应用程序修改此属性值的尝试预计会被该拥有机构忽视或拒绝。
https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-validation-02#section-9.4
如果采用JSON定义的value的含义，它是键右边的一位，后面跟着冒号。因此，我会将其视为价值的任何一部分。
OpenAPI规范仅真正将readOnly定义为适用于单个属性。
回答一个已经回答的问题，因为我想在接受的答案中添加更多细节，而且我有太多话要说，无法放入评论
根据JSONSchema规范，父对象(和数组(上的readOnly应该递归地应用于子属性(和元素(
以下是如何得出这个结论，从另一个答案中链接的定义开始：
如果"readOnly"；具有布尔值true，则表示该值实例的完全由拥有权限管理，并且应用程序修改此属性值的尝试预计会被该拥有机构忽视或拒绝。
https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-validation-02#section-9.4
因此，当在任何属性(包括对象/组和数组(上定义"readOnly"时，就意味着该属性的值不能更改。"更改"意味着将以前的值与新值进行比较。对对象和数组进行相等性检查的JSON模式定义如下
两者都是数组，并且对于项具有相等的值项
两者都是对象，其中的每个属性都有一个属性具有与另一个相等的键，并且该另一个属性具有价值
https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-02#section-4.2.3
在这两种情况下，"相等值"意味着相等检查应该是深度/递归的。这不是一个肤浅的平等检查。
因此，JSON模式意味着readOnly是递归的。如果您试图将更改应用于readOnly父对象/数组上的子属性/元素，则会发现父对象/阵列已更改，违反了readOnly断言。