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

docs: add operation definition for spec 3.0 #1006

Closed
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Merge branch 'master' into feature/operation-definition
buehlefs committed Apr 22, 2024
commit 8945fce23128f23094580c27a8f440a5caf78778
15 changes: 8 additions & 7 deletions spec/asyncapi.md
Original file line number Diff line number Diff line change
@@ -16,7 +16,7 @@ The AsyncAPI Specification is a project used to describe message-driven APIs in

The AsyncAPI Specification defines a set of fields that can be used in an AsyncAPI document to describe an [application](#definitionsApplication)'s API. The document may reference other files for additional details or shared fields, but it is typically a single, primary document that encapsulates the API description.

The file(s) SHOULD describe the [operations](#definitionsOperation) an [application](#definitionsApplication) performs. For instance, consider the following AsyncAPI definition snippet:
The AsyncAPI document SHOULD describe the [operations](#definitionsOperation) an [application](#definitionsApplication) performs. For instance, consider the following AsyncAPI definition snippet:

```yaml
channels:
@@ -104,7 +104,7 @@ Aside from the issues mentioned above, there may also be infrastructure configur
- [Multi Format Schema Object](#multiFormatSchemaObject)
- [Schema Object](#schemaObject)
- [Security Scheme Object](#securitySchemeObject)
- [OAuth Flows Object](#oauth-flows-object)
- [OAuth Flows Object](#oauth-flows-object)
- [OAuth Flow Object](#oauth-flow-object)
- [Server Bindings Object](#serverBindingsObject)
- [Parameters Object](#parametersObject)
@@ -143,11 +143,12 @@ An operation describes a specific action an [application](#definitionsApplicatio
A message is the mechanism by which information is exchanged via a channel between [servers](#definitionsServer) and applications. A message MAY 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.

### <a name="definitionsChannel"></a>Channel

A channel is an addressable component, made available by the [server](#definitionsServer), for the organization of [messages](#definitionsMessage). [Sender](#definitionsSender) applications send messages to channels and [receiver](#definitionsReceiver) applications receive messages from channels to perform an [operation](#definitionsOperation). [Servers](#definitionsServer) MAY support many channel instances, allowing messages with different content to be addressed to different channels. Depending on the [server](#definitionsServer) implementation, the channel MAY be included in the message via protocol-defined headers.

### <a name="definitionsProtocol"></a>Protocol

A protocol is the mechanism (wireline protocol or API) by which [messages](#definitionsMessage) are exchanged between the application and the [channel](#definitionsChannel). Example protocols include, but are not limited to, AMQP, HTTP, JMS, Kafka, Anypoint MQ, MQTT, Solace, STOMP, Mercure, WebSocket, Google Pub/Sub, Pulsar.
A protocol is the mechanism (wireline protocol or API) by which [messages](#definitionsMessage) are exchanged between the application and the [channel](#definitionsChannel). Example protocols include, but are not limited to, AMQP, HTTP, JMS, Kafka, Anypoint MQ, MQTT, Solace, STOMP, Mercure, WebSocket, Google Pub/Sub, Pulsar.

### <a name="definitionsBindings"></a>Bindings

@@ -399,7 +400,7 @@ Field Pattern | Type | Description
"protocol": "amqp",
"protocolVersion": "0-9-1",
"tags": [
{
{
"name": "env:development",
"description": "This environment is meant for developers to run their own tests."
}
@@ -411,7 +412,7 @@ Field Pattern | Type | Description
"protocol": "amqp",
"protocolVersion": "0-9-1",
"tags": [
{
{
"name": "env:staging",
"description": "This environment is a replica of the production environment."
}
@@ -423,7 +424,7 @@ Field Pattern | Type | Description
"protocol": "amqp",
"protocolVersion": "0-9-1",
"tags": [
{
{
"name": "env:production",
"description": "This environment is the live environment available for final users."
}
@@ -962,7 +963,7 @@ This object MAY be extended with [Specification Extensions](#specificationExtens

#### <a name="operationReplyAddressObject"></a>Operation Reply Address Object

An object that specifies where an [operation](#definitionsOperation) has to send the reply.
An object that specifies where an operation has to send the reply.

For specifying and computing the location of a reply address, a [runtime expression](#runtimeExpression) is used.

You are viewing a condensed version of this merge commit. You can view the full changes here.