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
Currently, where External Docs Object and Contact Object (in Info Object) can be defined, only one object of this type can be defined. I wonder if we should allow in version 3.0.0 to define externalDocs and contact as collections. I don't have any "production" use case, however I am thinking out loud. I wonder how the specification might be developed in the coming months/years and we should try to be prepared for incoming changes.
To leave compatibility with both AsyncAPI 2.x.x and OpenAPI we should still leave the possibility to define the discussed objects as a single object (the question is whether we should have compatibility?).
We have to agree on the possibility to define the discussed objects as a collection in the upcoming 3.0.0 release because this will be a breaking change on the tooling side - so we can't do this for the next 3.1.0 release and next ones.
Examples
External Docs (on Message Object)
messageId: userSignupname: UserSignuptitle: User signupsummary: Action to sign a user up.description: A longer descriptioncontentType: application/jsonexternalDocs:
- description: Find more info hereurl: https://example.com
- description: Another docurl: https://example.com
Contact (on Info Object)
contact:
- name: API Supporturl: https://www.example.com/supportemail: [email protected]
- name: Second supporturl: https://www.example.com/support2
The text was updated successfully, but these errors were encountered:
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.
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.
Currently, where
External Docs Object
andContact Object
(inInfo Object
) can be defined, only one object of this type can be defined. I wonder if we should allow in version3.0.0
to defineexternalDocs
andcontact
as collections. I don't have any "production" use case, however I am thinking out loud. I wonder how the specification might be developed in the coming months/years and we should try to be prepared for incoming changes.To leave compatibility with both AsyncAPI 2.x.x and OpenAPI we should still leave the possibility to define the discussed objects as a single object (the question is whether we should have compatibility?).
We have to agree on the possibility to define the discussed objects as a collection in the upcoming 3.0.0 release because this will be a breaking change on the tooling side - so we can't do this for the next 3.1.0 release and next ones.
Examples
External Docs (on Message Object)
Contact (on Info Object)
The text was updated successfully, but these errors were encountered: