Impart intelligence to swagger importer to handle generic object types in incoming swagger.

[springwiz]

Please do not post any internal, closed source snippets on this public issue tracker!

Current Sysl Version

0.136.0

Use-cases

Please describe the end goal you are trying to achieve that has led you to request this feature. Explore the possibility of creating wrapper response types automatically in the generated sysl when the incoming swagger uses generic response object types without any schema. This will allow the codegen to work from the generated sysl without the need of manual modification in the swagger/sysl.

For instance the incoming swagger fragment:

  /rest?method=flickr.favorites.getContext:
    get:
      operationId: getFavoritesContextByID
      description: Returns next and previous favorites for a photo in a user's favorites
      tags:
        - Public
      parameters:
        - name: api_key
          in: query
          required: true
          type: string
        - name: photo_id
          in: query
          required: true
          type: string
          pattern: ^[0-9]+$
        - name: user_id
          in: query
          required: false
          type: string
          pattern: ^([0-9]+@N[0-9]+)|([0-9a-zA-Z-_]+)$
      responses:
        200:
          description: OK
          schema:
            type: object
            properties:
              count:
                type: object
                properties:
                  _content:
                    type: string
              prevphoto:
                $ref: '#/definitions/ContextPhoto'
              nextphoto:
                $ref: '#/definitions/ContextPhoto'
              stat:
                $ref: '#/definitions/Stat'

Generates:

    /rest?method=flickr%2Efavorites%2EgetContext:
        GET ?api_key=string&photo_id=string&user_id=string?:
            | Returns next and previous favorites for a photo in a user's
            | favorites
            return ok <: object

    !type object:
        count <: object_object_count?:
            @json_tag = "count"
        nextphoto <: ContextPhoto?:
            @json_tag = "nextphoto"
        prevphoto <: ContextPhoto?:
            @json_tag = "prevphoto"
        stat <: Stat?:
            @json_tag = "stat"

The importer ends up generating a lot of such generic object types which makes codegen impossible. Make the solution configurable on the command line.

Attempted Solutions

Manual modification of the incoming swagger/sysl looks as the only solution.

References

• 2020

[ghost]

What are you expecting the sysl to look like? is it just the nameing of the objects or something else?

[springwiz]

Sysl should create wrapper types wherever possible. So lets say:

 /rest?method=flickr%2Efavorites%2EgetContext:
        GET ?api_key=string&photo_id=string&user_id=string?:
            | Returns next and previous favorites for a photo in a user's
            | favorites
            return ok <: PhotoResource

!type PhotoResource:
        count <: object_object_count?:
            @json_tag = "count"
        nextphoto <: ContextPhoto?:
            @json_tag = "nextphoto"
        prevphoto <: ContextPhoto?:
            @json_tag = "prevphoto"
        stat <: Stat?:
            @json_tag = "stat"

[ghost]

so yes, its just the name you dont like. Where is it supposed to get the wrapper name from? It already tries to give it a sensible name.

[springwiz]

So no not just the name, it has to use some kind of intelligent naming as the same scenario can repeat for multiple operations on an endpoint. The sysl ends up with multiple types named as "object" which results in invalid sysl.

[anzdaddy]

The long term solution is to extend to Sysl return syntax thus:

    /rest?method=flickr%2Efavorites%2EgetContext:
        GET ?api_key=string&photo_id=string&user_id=string?:
            | Returns next and previous favorites for a photo in a user's
            | favorites
            return ok <:
                count <: object_object_count?:
                    @json_tag = "count"
                nextphoto <: ContextPhoto?:
                    @json_tag = "nextphoto"
                prevphoto <: ContextPhoto?:
                    @json_tag = "prevphoto"
                stat <: Stat?:
                    @json_tag = "stat"