use of readOnly, writeOnly violates the spec (?) and usage with PUT etc

[karenetheridge]

I have implemented readOnly such that a property with that annotation cannot be used in requests (and similarly for writeOnly in responses). However, this prevents the labelling of a property as readOnly if it is to be used in a PUT, where (by REST convention) all properties are provided and the data overwrites the original idempotently -- here, the meaning is "this property may be present, but it can't change from its original value". As such it should only be treated as an annotation, and the application should figure out what to do with it, rather than generating a validation error itself.

Therefore:

• remove the checking of readOnly, writeOnly in validate_request and validate_response
• provide guidance (in cookbook documentation?) for getting these annotations out of the result and determining if the referenced properties are changing values.
• provide guidance for how to indicate that a particular propertly should not be present at all:

allOf:
  not:
    required: [id]
  not:
    required: [created]
  not:
    required: [updated]

or:

properties:
  id: false
  created: false
  updated: false

or:

$ref: '#/components/schemas/model.foo'
additionalProperties: false
properties:
  foo: true # property in model.foo
  bar: true # property in model.foo
  blah: true # property in model.foo

[karenetheridge]

[internal note: when this bug is fixed, I need to find places where these keywords are being used in \<that application> and update their schemas accordingly. These keywords can then be used in different places, as their annotation-only meanings, e.g. in /components/schemas/model.* to indicate that properties like 'id', 'created' etc are readOnly.]

[karenetheridge]

Perhaps a new x-disallow-readOnly: true keyword could be added into json schemas to look at these annotations and error when needed. Or, this keyword could be at the openapi level (say under content or under the media-type property) to indicate this.

[karenetheridge]

Henry had some good insights here: https://json-schema.slack.com/archives/C5CF75URH/p1663342158191369?thread_ts=1663339184.809749&cid=C5CF75URH