色综合久久天天综合绕观看,亚洲一区二区免费在线观看,国产jizz18高清视频

title: Users channel
description: This channel is used to exchange messages about user events.
messages:
userSignedUp:
$ref: '#/components/messages/userSignedUp'
userCompletedOrder:
$ref: '#/components/messages/userCompletedOrder'
parameters:
userId:
$ref: '#/components/parameters/userId'
servers:
- $ref: '#/servers/rabbitmqInProd'
- $ref: '#/servers/rabbitmqInStaging'
bindings:
amqp:
is: queue
queue:
exclusive: true
tags:
- name: user
description: User-related messages
externalDocs:
description: 'Find more info here'
url:‘https://example.com'

相比之下，使用合適的對象名稱定義的操作對象標識了可在此通道上調用的某些內容，并且僅使用引用對象來標識所使用的特定通道消息：

title: User sign up

summary: Action to sign a user up.

description: A longer description

channel:

  $ref: '#/channels/userSignup'

action: send

security:

  - petstore_auth:

    - write:pets

    - read:pets

tags:

  - name: user

  - name: signup

  - name: register

bindings:

  amqp:

    ack: false

traits:

  - $ref: "#/components/operationTraits/kafka"

messages:

  - $ref: '#/components/messages/userSignedUp'

reply:

  address:

    location: '$message.header#/replyTo'

  channel:

    $ref: '#/channels/userSignupReply'

  messages:

    - $ref: '#/components/messages/userSignedUpReply'

您會注意到，上面的 Operation 對象示例中有一些屬性反映了技術實現。但是，它主要側重于讓 API 提供者更容易定義操作，讓 API 使用者更簡單。對象的這種重用還將使用 AsyncAPI 編寫的 API 描述文檔更加簡潔。

支持請求-回復模式

AsyncAPI v3.0 的另一個顯著增強是正式支持請求-回復模式，這是一種非常常見的消息傳遞模式。許多人都熟悉Hophe 和 Wolf 所著《企業集成模式》中的請求-回復模式。作為一種架構模式，它顯然提供了客戶端如何提交請求并期望對該請求做出響應的通用視圖，使用同步或異步行為等待完整的響應或確認工作正在進行。

此模式的請求部分顯然由操作對象引用的消息對象表示。AsyncAPI v3.0 將操作回復對象引入到操作對象中，允許 API 提供者指定 API 使用者如何解析回復隊列。

再次以 v3.0 規范中的一個例子為例：

description: Consumer Inbox

location: $message.header#/replyTo

API 提供者向 API 使用者指示，可以從消息頭中檢索回復隊列值replyTo。該對象實現了運行時表達式，這意味著可以在環境中設置該值，而不是在 API 描述文檔中靜態提供。這顯然使文檔（因此使界面）變得更加可靠，并允許部署到不同的環境而不會影響 API 的形狀。

在OpenAPI和 AsyncAPI中，運行時表達式的使用非常普遍，值得一提的是，這種方法通常可以提高 API 描述文檔的靈活性。提供可以在運行時解析的指標（由適當的工具支持）意味著 API 提供者可以指定所需的行為而不是靜態值。這降低了脆弱性，并增加了 API 的給定版本獲得更長時間支持的機會。另請閱讀：

最后的想法：使用 AsyncAPI v3.0 的權衡

對于絕大多數用戶來說，AsyncAPI v3.0 中的開發將受到歡迎。簡化了指定操作的過程，省去了使用publish和subscribe屬性的負擔，使規范更容易理解。將通道和操作分離使得通道可以在操作之間重復使用，并簡化了操作的聲明。建立請求-回復語義也極大地有利于這種普遍異步模式的實施者。

這些變化也有可能使 AsyncAPI 成為企業集成的一項廣泛使用的功能。對象既可以從內部類型定義獲取，也可以從外部遠程定義獲取，這增強了更容易重用對象的能力。允許 API 生產商重用來自（例如）企業范圍 API 存儲庫的定義，為 API 治理提供了關鍵信息。此外，當 API 提供商修改用 AsyncAPI 編寫的 API 描述文檔時，他們可以輕松了解更改的影響。

因此，AsyncAPI 有可能在消息傳遞領域帶來巨大好處。在工具制造商和供應商的支持下，它可能會成為企業消息傳遞生態系統中 API 治理的支柱。

文章來源：What’s New in AsyncAPI v3.0?