From 54912402d22e54ccc7ee702010508a615856af7e Mon Sep 17 00:00:00 2001 From: Gerald Loeffler Date: Fri, 19 Mar 2021 16:06:03 +0100 Subject: [PATCH 1/3] clarifications on publish and subscribe While keeping the meaning of the AsyncAPI spec entirely unchanged, i've added clarifying statements on the meaning of the `publish` and `subscribe` operations. --- spec/asyncapi.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/spec/asyncapi.md b/spec/asyncapi.md index b9c84e2b..c4ea2fc5 100644 --- a/spec/asyncapi.md +++ b/spec/asyncapi.md @@ -4,7 +4,7 @@ Part of this content has been taken from the great work done by the folks at the [OpenAPI Initiative](https://openapis.org). Mainly because **it's a great work** and we want to keep as much compatibility as possible with the [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification). -#### Version 2.0.0 +#### Version 2.0.1 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://www.ietf.org/rfc/rfc2119.txt). @@ -25,7 +25,7 @@ user/signedup: $ref: "#/components/messages/userSignUp" ``` -It means that the [application](#definitionsApplication) allows [consumers](#definitionsConsumer) to subscribe to the `user/signedup` [channel](#definitionsChannel) to receive userSignUp [messages](#definitionsMessage). +It means that the [application](#definitionsApplication) allows [consumers](#definitionsConsumer) to subscribe to the `user/signedup` [channel](#definitionsChannel) to receive userSignUp [messages](#definitionsMessage) sent by the application. **The AsyncAPI specification does not assume any kind of software topology, architecture or pattern.** Therefore, a server MAY be a message broker, a web server or any other kind of computer program capable of sending and/or receiving data. However, AsyncAPI offers a mechanism called "bindings" that aims to help with more specific information about the protocol. @@ -81,13 +81,13 @@ It means that the [application](#definitionsApplication) allows [consumers](#def ## Definitions #### Application -An application is any kind of computer program or a group of them. It MUST be a [producer](#definitionsProducer), a [consumer](#definitionsConsumer) or both. An application MAY be a microservice, IoT device (sensor), mainframe process, etc. An application MAY be written in any number of different programming languages as long as they support the selected [protocol](#definitionsProtocol). An application MUST also use a protocol supported by the server in order to connect and exchange [messages](#definitionsMessage). +An application is any kind of computer program or a group of them. It MUST be a [producer](#definitionsProducer), a [consumer](#definitionsConsumer) or both. An application MAY be a microservice, IoT device (sensor), mainframe process, etc. An application MAY be written in any number of different programming languages as long as they support the selected [protocol](#definitionsProtocol). An application MUST also use a protocol supported by the server in order to connect and exchange [messages](#definitionsMessage). #### Producer -A producer is a type of application, connected to a server, that is creating [messages](#definitionsMessage) and addressing them to [channels](#definitionsChannel). A producer MAY be publishing to multiple channels depending on the server, protocol, and use-case pattern. +A producer is a type of application, connected to a server, that is creating [messages](#definitionsMessage) and addressing them to [channels](#definitionsChannel). A producer MAY be publishing to multiple channels depending on the server, protocol, and use-case pattern. The AsyncAPI document for a producer that sends messages to a given channel MUST use the [subscribe](#channelItemObjectSubscribe) operation on that channel to denote this fact. #### Consumer -A consumer is a type of application, connected to a server via a supported [protocol](#definitionsProtocol), that is consuming [messages](#definitionsMessage) from [channels](#definitionsChannel). A consumer MAY be consuming from multiple channels depending on the server, protocol, and the use-case pattern. +A consumer is a type of application, connected to a server via a supported [protocol](#definitionsProtocol), that is consuming [messages](#definitionsMessage) from [channels](#definitionsChannel). A consumer MAY be consuming from multiple channels depending on the server, protocol, and the use-case pattern. The AsyncAPI document for a consumer that receives messages from a given channel MUST use the [publish](#channelItemObjectPublish) operation on that channel to denote this fact. #### Message A message is the mechanism by which information is exchanged via a channel between servers and applications. A message MUST contain a payload and MAY also contain headers. The headers MAY be subdivided into [protocol](#definitionsProtocol)-defined headers and header properties defined by the application which can act as supporting metadata. The payload contains the data, defined by the application, which MUST be serialized into a format (JSON, XML, Avro, binary, etc.). Since a message is a generic mechanism, it can support multiple interaction patterns such as event, command, request, or response. @@ -555,8 +555,8 @@ Field Name | Type | Description ---|:---:|--- $ref | `string` | Allows for an external definition of this channel item. The referenced structure MUST be in the format of a [Channel Item Object](#channelItemObject). If there are conflicts between the referenced definition and this Channel Item's definition, the behavior is *undefined*. description | `string` | An optional description of this channel item. [CommonMark syntax](http://spec.commonmark.org/) can be used for rich text representation. -subscribe | [Operation Object](#operationObject) | A definition of the SUBSCRIBE operation. -publish | [Operation Object](#operationObject) | A definition of the PUBLISH operation. +subscribe | [Operation Object](#operationObject) | A definition of the SUBSCRIBE operation, which defines the messages sent by the application to the channel. +publish | [Operation Object](#operationObject) | A definition of the PUBLISH operation, which defines the messages received by the application from the channel. parameters | [Parameters Object](#parametersObject) | A map of the parameters included in the channel name. It SHOULD be present only when using channels with expressions (as defined by [RFC 6570 section 2.2](https://tools.ietf.org/html/rfc6570#section-2.2)). bindings | [Channel Bindings Object](#channelBindingsObject) \| [Reference Object](#referenceObject) | A map where the keys describe the name of the protocol and the values describe protocol-specific definitions for the channel. @@ -647,6 +647,8 @@ subscribe: Describes a publish or a subscribe operation. This provides a place to document how and why messages are sent and received. For example, an operation might describe a chat application use case where a user sends a text message to a group. +A publish operation describes messages that are received by the application, whereas a subscribe operation describes messages that are sent by the application. + ##### Fixed Fields Field Name | Type | Description From 82593745f5ee3586ec65d807cc4d515cb622a5ec Mon Sep 17 00:00:00 2001 From: Gerald Loeffler Date: Fri, 9 Apr 2021 16:46:00 +0200 Subject: [PATCH 2/3] incorporating Lukasz's feedback --- spec/asyncapi.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/spec/asyncapi.md b/spec/asyncapi.md index c4ea2fc5..9c28b61b 100644 --- a/spec/asyncapi.md +++ b/spec/asyncapi.md @@ -4,7 +4,7 @@ Part of this content has been taken from the great work done by the folks at the [OpenAPI Initiative](https://openapis.org). Mainly because **it's a great work** and we want to keep as much compatibility as possible with the [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification). -#### Version 2.0.1 +#### Version 2.0.0 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://www.ietf.org/rfc/rfc2119.txt). @@ -25,7 +25,7 @@ user/signedup: $ref: "#/components/messages/userSignUp" ``` -It means that the [application](#definitionsApplication) allows [consumers](#definitionsConsumer) to subscribe to the `user/signedup` [channel](#definitionsChannel) to receive userSignUp [messages](#definitionsMessage) sent by the application. +It means that the [application](#definitionsApplication) allows [consumers](#definitionsConsumer) to subscribe to the `user/signedup` [channel](#definitionsChannel) to receive userSignUp [messages](#definitionsMessage) produced by the application. **The AsyncAPI specification does not assume any kind of software topology, architecture or pattern.** Therefore, a server MAY be a message broker, a web server or any other kind of computer program capable of sending and/or receiving data. However, AsyncAPI offers a mechanism called "bindings" that aims to help with more specific information about the protocol. @@ -84,10 +84,10 @@ It means that the [application](#definitionsApplication) allows [consumers](#def An application is any kind of computer program or a group of them. It MUST be a [producer](#definitionsProducer), a [consumer](#definitionsConsumer) or both. An application MAY be a microservice, IoT device (sensor), mainframe process, etc. An application MAY be written in any number of different programming languages as long as they support the selected [protocol](#definitionsProtocol). An application MUST also use a protocol supported by the server in order to connect and exchange [messages](#definitionsMessage). #### Producer -A producer is a type of application, connected to a server, that is creating [messages](#definitionsMessage) and addressing them to [channels](#definitionsChannel). A producer MAY be publishing to multiple channels depending on the server, protocol, and use-case pattern. The AsyncAPI document for a producer that sends messages to a given channel MUST use the [subscribe](#channelItemObjectSubscribe) operation on that channel to denote this fact. +A producer is a type of application, connected to a server, that is creating [messages](#definitionsMessage) and addressing them to [channels](#definitionsChannel). A producer MAY be publishing to multiple channels depending on the server, protocol, and use-case pattern. #### Consumer -A consumer is a type of application, connected to a server via a supported [protocol](#definitionsProtocol), that is consuming [messages](#definitionsMessage) from [channels](#definitionsChannel). A consumer MAY be consuming from multiple channels depending on the server, protocol, and the use-case pattern. The AsyncAPI document for a consumer that receives messages from a given channel MUST use the [publish](#channelItemObjectPublish) operation on that channel to denote this fact. +A consumer is a type of application, connected to a server via a supported [protocol](#definitionsProtocol), that is consuming [messages](#definitionsMessage) from [channels](#definitionsChannel). A consumer MAY be consuming from multiple channels depending on the server, protocol, and the use-case pattern. #### Message A message is the mechanism by which information is exchanged via a channel between servers and applications. A message MUST contain a payload and MAY also contain headers. The headers MAY be subdivided into [protocol](#definitionsProtocol)-defined headers and header properties defined by the application which can act as supporting metadata. The payload contains the data, defined by the application, which MUST be serialized into a format (JSON, XML, Avro, binary, etc.). Since a message is a generic mechanism, it can support multiple interaction patterns such as event, command, request, or response. @@ -645,9 +645,9 @@ subscribe: #### Operation Object -Describes a publish or a subscribe operation. This provides a place to document how and why messages are sent and received. For example, an operation might describe a chat application use case where a user sends a text message to a group. +Describes a publish or a subscribe operation. This provides a place to document how and why messages are sent and received. -A publish operation describes messages that are received by the application, whereas a subscribe operation describes messages that are sent by the application. +For example, an operation might describe a chat application use case where a user sends a text message to a group. A publish operation describes messages that are received by the chat application, whereas a subscribe operation describes messages that are sent by the chat application. ##### Fixed Fields From 2814f45f7ee276817196655203db50b9631afc4c Mon Sep 17 00:00:00 2001 From: Gerald Loeffler Date: Fri, 9 Apr 2021 16:49:54 +0200 Subject: [PATCH 3/3] Sticking to produce/consume as much as possible --- spec/asyncapi.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/asyncapi.md b/spec/asyncapi.md index 9c28b61b..fbab9f6d 100644 --- a/spec/asyncapi.md +++ b/spec/asyncapi.md @@ -555,8 +555,8 @@ Field Name | Type | Description ---|:---:|--- $ref | `string` | Allows for an external definition of this channel item. The referenced structure MUST be in the format of a [Channel Item Object](#channelItemObject). If there are conflicts between the referenced definition and this Channel Item's definition, the behavior is *undefined*. description | `string` | An optional description of this channel item. [CommonMark syntax](http://spec.commonmark.org/) can be used for rich text representation. -subscribe | [Operation Object](#operationObject) | A definition of the SUBSCRIBE operation, which defines the messages sent by the application to the channel. -publish | [Operation Object](#operationObject) | A definition of the PUBLISH operation, which defines the messages received by the application from the channel. +subscribe | [Operation Object](#operationObject) | A definition of the SUBSCRIBE operation, which defines the messages produced by the application and sent to the channel. +publish | [Operation Object](#operationObject) | A definition of the PUBLISH operation, which defines the messages consumed by the application from the channel. parameters | [Parameters Object](#parametersObject) | A map of the parameters included in the channel name. It SHOULD be present only when using channels with expressions (as defined by [RFC 6570 section 2.2](https://tools.ietf.org/html/rfc6570#section-2.2)). bindings | [Channel Bindings Object](#channelBindingsObject) \| [Reference Object](#referenceObject) | A map where the keys describe the name of the protocol and the values describe protocol-specific definitions for the channel.