re-write the openapi file using asyncapi specification.

[Souvikns]

So to rebuild this project with glee, the first step would be to convert the openapi file to AsyncAPI.

We might have some issues with certain parts of the spec like the response and multi-method support in aysncapi spec 2.0, but let's give it a try, if it is not possible then we could just create a WebSocket API instead.

[Souvikns]

Let's try to convert this channel from https://github.com/Souvikns/server-api/blob/master/openapi.yaml to AsyncAPI document successfully.

OpenAPI

  /validate:
    post:
      summary: Validate the given AsyncAPI document.
      operationId: validate
      tags:
        - validate
        - parser
      externalDocs:
        name: Github Repository for the AsyncAPI Parser
        url: https://github.com/asyncapi/parser-js
      requestBody:
        description: Validate the given AsyncAPI document.
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/ValidateRequest'
      responses:
        "204":
          description: The given AsyncAPI document is valid.
        "400":
          description: The given AsyncAPI document is not valid.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Problem"
        "422":
          description: The given AsyncAPI document is not valid due to invalid parameters in the request.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Problem"
        default:
          description: Unexpected problem.
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Problem"

AsyncAPI

/validate:
  tags:
    - validate
    - parser
  operationId: validate
  bindings:
    http:
      method: POST
  publish:
    $ref: '#/components/schemas/ValidateRequest'
  subscribe:
    payload:
      responses:
        type: object
        properties:
          204:
            type: object
            properties:
              description:
                type: string
          400:
            type: object
            properties:
              description:
                type: string
              content:
                $ref: '#/components/schemas/Problem'
          422:
            type: object
            properties:
              description:
                type: string
              content:
                $ref: '#/components/schemas/Problem'
          default:
            type: object
            properties:
              description:
                type: string
              content:
                $ref: '#/components/schemas/Problem'

We can define the doc into AsyncAPI just feels a bit weird with the response, maybe we can handle it in glee, ask users to follow a standard format for responses in HTTP protocol.

@KhudaDad414 what do you think?

[KhudaDad414]

We have a standard format for AsyncAPI, it's called bindings. 😆 I think this problem runs deeper than this. We need to have a discussion on the http bindings. I see there are a few points already raised here https://github.com/asyncapi/bindings/issues/2. let's start from there :)

[Souvikns]

Yeah I had tried to push this before and one thing we were trying to do was trying to reuse the open API schema here but it didn't work. you can look at https://github.com/asyncapi/bindings/pull/131 I think this is solved in v3 when we have operations, but that brings up the question of how the bindings should evolve according to v3.0 of spec.