Add message type to describe Event/Command/Other

[rj93]

Messages are frequently either considered to be Commands or Events, there is even a brief section in the docs about it.

However the message spec doesn't currently have anyway to differnaitate these types of messages.

This could potentially be useful in the code generators to either implement "server" or "client" implementations.

Servers would generate the listeners for commands, and emitters for events. While clients would generate the inverse.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[ishyverma]

Hey! @rj93 can you tell me exactly how to give the message the type server or client ? I want to contribute to this issue. Thanks !!😊

[Manush-2005]

Hey @rj93 , I would like to take up this issue.

[ashug06]

Hi @rj93 ! I'm Ashutosh goyal, a contributor eager to help with the AsyncAPI project. I’m excited to be involved in improving the specifications and learning more about the project. Looking forward to collaborating with everyone here!

[shwetd19]

Hey @rj93! This is a great idea—it could make AsyncAPI specs more expressive and improve code generation. Message classification is a key part of event-driven architectures, so formalizing it in the spec makes a lot of sense.

Building on this, what do you think about adding a messageType field to the Message Object with possible values like:

• event – A notification about something that happened
• command – A request to perform an action
• query – A request that returns data
• document – A message that represents a data snapshot

This could make things clearer for code generators while still being flexible for different messaging patterns. We’d also need to decide if it should be a required field or optional.

I’d love to contribute and help work through the technical details! 🚀

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️