Есть ли еще примеры использования readOnly на нескольких уровнях схемы для пояснения семантики? - PullRequest
Новая
       3

Есть ли еще примеры использования readOnly на нескольких уровнях схемы для пояснения семантики?

0 голосов
/ 25 марта 2020

Я использовал ключевое слово readOnly в своих схемах, и я только что понял, что просто создаю свою собственную семантику. Сейчас я очищаю кучу своих проектов и пытаюсь подтвердить, что я использовал эту аннотацию, как и было задумано. проверка правильности spe c - это то, на чем я основываю этот вопрос, но я хотел бы знать больше примеров использования сценария ios.

Позвольте мне привести три примера. В этом первом примере я хочу сказать, что весь ресурс доступен только для чтения. Ничто не может быть мутировал на любом уровне. 

{
    "type": "object",
    "readOnly": true,
    "properties": {
        "name": {
            "type": "string",
        },
        "members": {
            "type": "object",
            "properties": {
                "member1": { "type" : "string" },
                "member2": { "type" : "string" }
            }
        }
    }
}

Я не думаю, что это слишком спорный. Но изначально моя собственная ментальная модель заключалась в том, что readOnly на верхнем уровне означало, что вы не можете заменить этот ресурс новым ресурсом. Сервер предотвратит это. Но внутренние члены были все еще изменчивы. Поэтому я добавил readOnly в подсхему name и подсхему каждого члена. Я думаю, что удаление всех из них было правильным. (Моя ментальная модель, возможно, была основана на том, как я интерпретирую константные переменные в 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 являются неизменяемыми. member3 и member4 могут быть изменены.

Так что вопрос в том, есть ли что-то неправильное в моей интерпретации readOnly?

1 Ответ

0 голосов
/ 25 марта 2020

Спецификация c, как вы связали, определяет следующее для readOnly ...

Если «readOnly» имеет значение логического true, это означает, что значение экземпляра управляется исключительно владельцем, и попытки приложения изменить значение этого свойства, как ожидается, будут игнорироваться или отклоняться этим владельцем.

https://tools.ietf.org/html/draft-handrews-json-schema-validation-02#section -9.4

Если принять JSON определенное значение value, это бит справа от ключа, за которым следует двоеточие. Поэтому я бы прочитал это как любую часть значения.

Спецификация OpenAPI действительно определяет только readOnly как применимую к отдельным свойствам.

...