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.

Sign up for GitHub

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

Jump to bottom

feat: add core message payload validation #334

Merged
merged 7 commits into from
Mar 13, 2023
Merged

feat: add core message payload validation #334

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
8c9f3d7
add messageObject
jonaslagoni Feb 9, 2023
997328d
add validation
jonaslagoni Feb 9, 2023
ed2da91
Merge branch 'next-major-spec' into feature/validate_some_message_pay…
jonaslagoni Feb 13, 2023
8d5c6d4
Merge branch 'next-major-spec' into feature/validate_some_message_pay…
jonaslagoni Feb 22, 2023
5d098fe
fixed some problems with default message format
jonaslagoni Feb 22, 2023
9f1b76f
fixed message object
jonaslagoni Feb 22, 2023
44cdada
Merge branch 'next-major-spec' into feature/validate_some_message_pay…
jonaslagoni Feb 22, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
84 changes: 84 additions & 0 deletions definitions/3.0.0/messageObject.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -154,6 +154,90 @@
}
}
},
"allOf": [
{
"if": {
"not": {
"required": [
"schemaFormat"
]
}
},
"then": {
"properties": {
"payload": {
"$ref": "http://asyncapi.com/definitions/3.0.0/schema.json"
}
}
}
},
{
"if": {
"required": [
"schemaFormat"
],
"properties": {
"schemaFormat": {
"enum": [
"application/vnd.aai.asyncapi;version=2.0.0",
"application/vnd.aai.asyncapi+json;version=2.0.0",
"application/vnd.aai.asyncapi+yaml;version=2.0.0",
"application/vnd.aai.asyncapi;version=2.1.0",
"application/vnd.aai.asyncapi+json;version=2.1.0",
"application/vnd.aai.asyncapi+yaml;version=2.1.0",
"application/vnd.aai.asyncapi;version=2.2.0",
"application/vnd.aai.asyncapi+json;version=2.2.0",
"application/vnd.aai.asyncapi+yaml;version=2.2.0",
"application/vnd.aai.asyncapi;version=2.3.0",
"application/vnd.aai.asyncapi+json;version=2.3.0",
"application/vnd.aai.asyncapi+yaml;version=2.3.0",
"application/vnd.aai.asyncapi;version=2.4.0",
"application/vnd.aai.asyncapi+json;version=2.4.0",
"application/vnd.aai.asyncapi+yaml;version=2.4.0",
"application/vnd.aai.asyncapi;version=2.5.0",
"application/vnd.aai.asyncapi+json;version=2.5.0",
"application/vnd.aai.asyncapi+yaml;version=2.5.0",
"application/vnd.aai.asyncapi;version=2.6.0",
"application/vnd.aai.asyncapi+json;version=2.6.0",
"application/vnd.aai.asyncapi+yaml;version=2.6.0",
Comment on lines +182 to +202
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because there are no changes to the schema across all v2 versions and v3, I guess it makes sense to validate it against these, right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it does make sense. Better to be explicit ;]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned about having to maintain this list, add new elements per version, etc.

Can we use a pattern instead of enum here?

{
  "type": "string",
  "pattern": "^application\\/vnd\\.aai\\.asyncapi(\\+json|\\+yaml)?;version=\\d+\\.\\d+\\.\\d+$"
}

Maybe some change is needed. You can test it in https://www.jsonschemavalidator.net/s/VTaBCoGr

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure we dont want to enable v1 or future v4 schemas here right? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also would we not want to explicitly state which schema formats are allowed as values? Using something like v2.69.0 would not give a validation error with regex 🤔

Unless you explicitly add a range, but then you are back to having to change this each version anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

Also thinking about new features being added between versions (no breaking changes). For example, let's say 3.1.0 introduces a new field in the schema so you will have to do a split, serving one schema for >=2.x <=3.0, and another for 3.1.

Porting this to the pattern will be a bit messy. I don't like to maintain all this list but indeed i can't find a better alternative ATM but automating somehow this (we can think about in near future).

"application/vnd.aai.asyncapi;version=3.0.0",
"application/vnd.aai.asyncapi+json;version=3.0.0",
"application/vnd.aai.asyncapi+yaml;version=3.0.0"
]
}
}
},
"then": {
"properties": {
"payload": {
"$ref": "http://asyncapi.com/definitions/3.0.0/schema.json"
}
}
}
},
{
"if": {
"required": [
"schemaFormat"
],
"properties": {
"schemaFormat": {
"enum": [
"application/schema+json;version=draft-07",
"application/schema+yaml;version=draft-07"
]
}
}
},
"then": {
"properties": {
"payload": {
"$ref": "http://json-schema.org/draft-07/schema"
}
}
}
}
],
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://asyncapi.com/definitions/3.0.0/messageObject.json"
}