Why AsyncAPI binding for HTTP when we have Open API

[iqbal-h]

Hello, This topic may be very basic for the experts out there, but still, I want to initiate it for a clear understanding. I understand that OpenAPI is essential for representing request/response, and Async is for pub/sub (please correct me if I need to be corrected somewhere). However, Async API provides binding that one can use to represent HTTP messages and other formats. My questions are the following:

1. Why do we need such a binding facility to represent request/response when we already have OpenAPI?
2. In what cases do we need AsyncAPI to represent messages as HTTP using binding?
3. Can we represent an architecture comprising both pub/sub and HTTP messages using only AsyncAPI?
4. How is HTTP representation in AsyncAPI different from Open API?

This discussion aims to clearly understand the purpose behind each API and why cross-compatibility is provided using binding.
Thanks.

[derberg]

@iqbal-h current HTTP binding is pretty basic and experimental. For example you can have only one method per channel.

There are use cases in event-driven world where HTTP protocol is needed. And yes, reinventing the wheel is always bad and should always be a last resort. This is why there are discussions/experiments to enable the reuse of OpenAPI inside AsyncAPI.

Both, OpenAPI and AsyncAPI are needed.
You can see some work here asyncapi/bindings#131

[derberg]

@Souvikns @fmvilas interesting discussion for you