bee-travels/openapi-comment-parser

Add support for "inline" objects in response and request body

mbokinala opened this issue · 6 comments

I want to use the responseContent comment to specify an object response

What do you mean by inline?

I think it's for jsodc object (schema) declaration like beelow

/**
 * SCHEMAS JWS
 * {
 *   "header": ... ,
 *   "payload": ... ,
 *   "signature": ....
 * }
/*

/**
 * POST /auth/token
 * @summary Return a valid jwt
 * @bodyContent {JWS} A valid Jws with x5c cert chain
 * @bodyRequired
 * @description Get a valid jwt
 * @response 200 - OK
 * @responseContent {jwt} 200.application/json
 */

or something like that or directly in yml.

I need this too ;) It's juste for convenience to declare schemas where they are used.

Ah gotcha, I went with yaml because I don’t like dealing with whitespace in jsdoc. But it shouldn’t be too hard to add if people find it useful :)

I’d also be happy to merge any pull requests if someone wanted to take a stab at building the feature?

I could do that cause I need it !

:)

two proposals.
First of all a simple part of component declaration in yml like we discuss before

/**

        components:
          schemas:
            JWS:
              properties:
                header:
                  type: string
                payload:
                  type: string
                signature:
                  type: string
    **/

or use the https://github.com/john-doherty/jsdoc-to-json-schema proposal

/**
 * @schema.name JWS
 */
const JWS = {

    /**
     * @schema.title Header
     * @schema.type string
     * @schema.required true
     */
    header: '',

 /**
     * @schema.title Payload
     * @schema.type string
     * @schema.required true
     */
    payload: '',

 /**
     * @schema.title Signature
     * @schema.type string
     * @schema.required true
     */
    signature: '',
}

John use the jsdoc schema tag it's quite concise format in jsdoc and refer directly to an object creation.
The integration is more straigth forward with the second because of the JSON schema integration in openAPI format.

I could try today an implementation of the second. Tel me @bourdakos1 if you think it's a good idea in order to merge it of course ! ;)

I really like the second example! Would be more than happy to merge that feature 😁