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

Feature: Support for operationId #25

Closed
acrilex1 opened this issue Nov 2, 2020 · 3 comments · Fixed by #52
Closed

Feature: Support for operationId #25

acrilex1 opened this issue Nov 2, 2020 · 3 comments · Fixed by #52

Comments

@acrilex1
Copy link

acrilex1 commented Nov 2, 2020

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:

/**
 * Method to validate the Payload against schema definition using an OperationId.
 * @param {string} operationId - required - operationId
 * @param {Object} payload - required - payload of the message
 * @returns {boolean} 
 */
validateByOperationId(operationId, payload);

I'll be glad to submit a PR if the idea is acceptable.

Thanks!

@WaleedAshraf
Copy link
Owner

Hi,

You'd still need a key and msgIdentifier. As one operation can have multiple messages. This could be solved if there was messageId filed defined in AsyncAPI, just like operationId. I'll check the AsyncAPI team on this.

So, the end method would look like
validateByOperationId(key, payload, operationId)

If AsyncAPI Schema adds support for messageId, then it can be,
validateByMessageId(messageId, payload)

@acrilex1
Copy link
Author

acrilex1 commented Nov 3, 2020

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.

@WaleedAshraf
Copy link
Owner

@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 validateByMessageId(messageId, payload). That would simplify a lot of things, and we can also get rid of msgIdentifier.

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

Successfully merging a pull request may close this issue.

2 participants