Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion, Feature Request] precise definitions of additionalProperties key and value types #2241

Closed
atothek1 opened this issue May 27, 2020 · 1 comment

Comments

@atothek1
Copy link

To enable a precise definition for additional properties especially for automated processing of API contract, like code generation I suggest the following new keyword in addition of the type property to define the key type and the value type.

keyOf:

  • can be of any valid scalar type provided by the OpenAPI specs
  • can be a reference to an enum definition
MyKeyEnum:
  type: string
  enum:
    - A
    - B
    - C
MyDictionary:
  type: object
  additionalProperties:
    keyOf:
      - $ref: '#/components/schemas/MyKeyEnum'
    type: string

or with multiple value types allowed

MyKeyEnum:
  type: string
  enum:
    - A
    - B
    - C
MyDictionary:
  type: object
  additionalProperties:
    keyOf:
      - $ref: '#/components/schemas/MyKeyEnum'
    anyOf:
      - type: string
      - type: integer
@handrews
Copy link
Member

@atothek1 JSON Schema added propertyNames for this a few drafts ago. It works slightly differently:

MyDictionary:
  type: object
  propertyNames:
    $ref: '#/components/schemas/MyKeyEnum'
  additionalProperties:
    type: string

This has the same effective behavior as your proposal when patternProperties and properties are not present, but slightly different behavior if they are present (because they affect additionalProperties and not propertyNames. However, that can usually be worked around. And mostly propertyNames + additionalProperties are used when properties and patternProperties are not being used, because those other keywords already constrain the names.

OAS 3.1 (out soon!) will include full compatibility with the most recent JSON Schema draft, so this will be addressed automatically in that release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants