Can a full REST API, assume all the HTTP Methods are used, for a single URL be documented?

[upsampled]

I like AsyncAPI because it embraces multiple protocols, specifically websockets which i use often. The problem is that I still have the document the legacy REST APIs in order to extend them and I cannot document all the HTTP Methods they support.

  /v1/bus:
    description: involves requesting an action be performed on a bus
    servers: ['LegacyREST']
    subscribe:
      bindings:
        http:
          type: request
          method: GET
          query:
            $ref: './query.yml#/bus'
      message:
        $ref: './message.yml#/bus'
    publish:
        bindings:
          http:
            type: request
            method: PUT
            query:
              $ref: './message.yml#/bus'

Right now I have only been able to assign one HTTP method to subscribe and publish. Subscribe can probably just stay associated with GET, but publish really needs to be associated with PUT, POST, PATCH, DELETE. I realize you can try to get around the two method restriction with REST call that have arguments in the URL (IE: /v1/bus/{id}), but that doesn't help me if I am documenting an API that was already created with only query arguments.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[smoya]

Hi @upsampled !

Unfortunately, there is no way right now to declare multiple operations of the same type (publish/subscribe) in the same channel.
This is something that the 3.0.0 version of the spec will solve by Moving operations to its own root object, allowing you to assign all the operations you want to a single channel.

The first workaround I thought about but that it's not possible to do in your case is to create several channels. But in your case, you need to declare those several HTTP Methods to a single path on your API. Since channels are identified by their address atm, you won't be able to create any other. (btw, this is also fixed in 3.0.0 by: Let channels be identified by an ID rather than their address.)

Maybe other colleagues have a workaround for your case cc @magicmatatjahu @fmvilas @derberg @dalelane

[smoya]

If you agree @upsampled, could we close this issue? @derberg

[upsampled]

Closing ticket but would definitely suggest this be marked as a use case/example for the v3 release. Lots of REST projects out there that could be extended cleanly with Async API.

[smoya]

@upsampled there is some WIP PR that might solve your issue: asyncapi/bindings#131, but I'm not pretty sure if it will move forward TBH.