-
Notifications
You must be signed in to change notification settings - Fork 11
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
Feature: Support for operationId #25
Comments
Hi, You'd still need a So, the end method would look like If AsyncAPI Schema adds support for messageId, then it can be, |
Ah yes sorry, I misunderstood the method. I was thinking in a way to validate the payload. In that case, there could be a way to validate all messages in an operation. In fact, if it can help for understanding, I would like to simply provide an object with all messages enclosed by their name for an operation and get them validated. So, the proposed implementation would be to add an OperationValidator.js file with a method with same signature as I originally mentionned. This method would validate all the messages in an operation. However, after reading the specification, I am not sure if the use case I mention would be valid. It validated using the online Playground, but it might be a bug. The format I try to validate is as bellow: asyncapi: 2.0.0
info:
title: Minimal demo
version: '1.0.0'
license: [...]
servers: [...]
channels:
/example:
subscribe:
operationId: onExample
message:
payload: [...]
publish:
operationId: sendExample
message:
payload: [...]
bindings: [...] The part where I am not sure is the position of the OperationId. |
@alexandre-okidoo Validating all messages in one operation in one go would not work. As each message can have its own schema. You would still need to have a way to identify which payload points to which message. I have created a feature request as can see ^. When it's there, we can add method |
Hello,
It would be great to add support for validating messages using OperationId in addition to the regular key, channel and operation way. The advantage would be that an operationId is usually immutable after designed while the rest of the parameters could change. For example, sometimes we change the key or the channel name, but (at least the way I design), the operation ID remains the same. This way of doing things is quite useful when using a generated client (such as in OpenAPI), for which the exact channel name would be an implementation detail, with an abstraction layer based on the tag and the operationId.
The operationId field is defined in the AsyncAPI specification as an id that "[...] MUST be unique among all operations described in the API." (https://www.asyncapi.com/docs/specifications/2.0.0#fixed-fields-7), so it would be sufficient to search the YAML for the specified ID in order to run the validation.
Proposed implementation:
I'll be glad to submit a PR if the idea is acceptable.
Thanks!
The text was updated successfully, but these errors were encountered: