You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 7, 2024. It is now read-only.
OpenAPI (in both of version 2.0 and the upcoming 3.0) uses an extended subset of JSON schema for their schema definitions.
As often REST APIs are defined via OpenAPI and services want to use the same definition for both the Nakadi event schema and their "Restful" API, it would be useful if valid OpenAPI schemas would also be supported here.
The main differences are some additional fields, which are not in JSON schema. Here the list for OpenAPI 2.0:
@rcillo what do you think about this? The issue I see is that we use a third party library for schema validation, and I don't know how it will behave with these properties.
@lmontrieux it's already allowed to use these attributes under "forward" mode. They behave as @ePaul suggested: they are no-op. Changes to them are not regulated by compatibility checks, i.e. one could remove attributes from x-extensible-enum and we would not complain.
We just do not support them for "compatible". That would be much harder and the evolution rules would have to be reviewed.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
OpenAPI (in both of version 2.0 and the upcoming 3.0) uses an extended subset of JSON schema for their schema definitions.
As often REST APIs are defined via OpenAPI and services want to use the same definition for both the Nakadi event schema and their "Restful" API, it would be useful if valid OpenAPI schemas would also be supported here.
The main differences are some additional fields, which are not in JSON schema. Here the list for OpenAPI 2.0:
For 3.0 we get (link to implementer's draft RC0) in addition
My proposal is to simply accept and ignore those properties when they are encountered instead of refusing the event type definition.
This would e.g. allow to use
x-extensible-enum
to describe a property with an extensible enum.The text was updated successfully, but these errors were encountered: