[OAS 3.0.0] yaml with multiple server urls generates code using first url only

[hippoKnight]

Description

I wrote a yaml following OAS 3.0, its servers part looked like this:

...
#--- server ---#
servers:
  # server object
  - url: http://1.1.1.1:9200/
  - url: http://1.1.1.1:9201/v2
...

I used this yaml generating python code, and didn' t see the second url('http://1.1.1.1:9201/v2')

So, my question is: What is the desired result if the yaml contains multiple urls?

openapi-generator version

I installed openapi-generator using Homebrew yesterday.

OpenAPI declaration file content or url

#--- OpenAPI version ---#
openapi: '3.0.0'

#--- metadata about the api ---#
info:
  # title of the application
  title: '9'

  # description of the application
  description: '9'

  # terms of service for the API, must be a URL
  termsOfService: ''

  # contact information for the exposed API
  contact:
    name: 'myname'
    url: 'myurl'
    email: 'my@mail.com'

  # license information for the exposed API
  license:
    name: 'myname'
    url: 'myurl'

  # version of the OpenAPI document
  version: '1.0.1'

#--- additional external documentation ---#
externalDocs:
  description: '9'
  url: ''

#--- server ---#
servers:
  # server object
  - url: http://1.1.1.1:9200/
  - url: http://1.1.1.1:9201/v2
    # URL to the target host

    # map between a variable name and its value(used for substitution in the server's URL template)
    variables:
      basePath:
        enum:
          - ''
          - 'website/face/v2/'
          - 'business/api/'
        default: ''
        description: 'basePath'

      username:
        default: 'admin'
        description: 'username'

    description: 's'

#--- tags for specification with additional metadata ---#
tags:
  - name: 'website'
    description: 'API of website operations'

security:
  # only one of the security requirement objects need to be satisfied to authorize a request
  # mentioned names must in components-seuritySchemes
  -
    cookieAuth_sessionId: []
    cookieAuth_ytClusterId: []
    # lists the required security schemes to execute this operation
    # objects that contain multiple schemes require all satisfication

#--- reusable objects for the specification ---#
components:


  # Security scheme definitions (see Authentication)
  securitySchemes:
    # https://swagger.io/specification/#securitySchemeObject
    cookieAuth_sessionId:
      type: 'apiKey'
      in: 'cookie'
      name: 'session_id'

    cookieAuth_ytClusterId:
      type: 'apiKey'
      in: 'cookie'
      name: 'yt_cluster_id'

  # Reusable schemas (data models)
  schemas:
    # definition of input and output data types
    # can be objects, primitives, arrays
    # https://swagger.io/specification/#schemaObject

    sessionID:
      type: 'string'


    clusterID:
      type: 'string'

    # user login info: name & password
    LoginInfo:
      type: 'object'
      required:
        - name
        - password
      properties:
        name:
          type: 'string'
        password:
          type: 'string' # password should be a md5 format string

    LoginResponseInfo:
      type: 'object'
      required:
        - session_id
      properties:
        session_id:
          type: 'string'
        cluster_id:
          type: 'string'

    # response info for all API: rtn & message
    ResponseInfo:
      type: 'object'
      required:
        - rtn
        - message
      properties:
        rtn:
          type: 'integer'
          # format: 'int32'
        message:
          type: 'string'

    # repository info for creation: repository name and extra_meta
    repoCreationInfo:
      type: 'object'
      required:
        - name
      properties:
        name:
          type: 'string'
        extra_meta:
          type: 'object'
          additionalProperties: {}
          # or can be written as: additionalProperties: true

    # repository id info
    repoIdInfo:
      type: 'object'
      required:
        - id
      properties:
        id:
          type: 'string'


  # Reusable request bodies
  requestBodies:
    LoginBody:
      description: 'A JSON object containing the login and password'
      required: true
      content:
        'application/json':
          schema:
            $ref: '#/components/schemas/LoginInfo'
          # examples:
          #   LoginInfo_admin:
          #     $ref: '#/components/examples/LoginInfo_example'

    repoCreationBody:
      description: 'A JSON object containing the repository name and meta info'
      required: true
      content:
        'application/json':
          schema:
            $ref: '#/components/schemas/repoCreationInfo'

  # Reusable responses, such as 401 Unauthorized or 400 Bad Request
  responses:

    # default response model
    DefaultResponse:
      description: 'Error: rtn != 0'
      headers: ''
      content:
        'application/json':
          schema:
            $ref: '#/components/schemas/ResponseInfo'

    # successful login response model
    LoginResponse:
      description: 'Successful login: The session ID is returned in a cookie named `session_id` and you need to include this cookie in subsequent requests'
      headers:
        Set-cookie:
          schema:
            allOf:
              - $ref: '#/components/schemas/sessionID'
              - $ref: '#/components/schemas/clusterID'
            # type: 'string'
            # example: 'session_id=111@DEFAULT; yt_cluster_id=DEFAULT'
      content:
        'application/json':
          schema:
            anyOf:
              - $ref: '#/components/schemas/ResponseInfo'
              - $ref: '#/components/schemas/LoginResponseInfo'

    repoCreationResponse:
      description: 'Successful repo_creation'
      content:
        'application/json':
          schema:
            anyOf:
              - $ref: '#/components/schemas/ResponseInfo'
              - $ref: '#/components/schemas/repoIdInfo'



#--- available paths and operations for the API ---#
paths:

  # path for user login
  /login:
    post:
      tags:
        # - 'user'
        - 'business'
      summary: 'user login'
      description: 'user login with user name and password'
      operationId: 'userLogin'
      requestBody:
        $ref: '#/components/requestBodies/LoginBody'
      responses:
        '200':
          $ref: '#/components/responses/LoginResponse'
        'default':
          $ref: '#/components/responses/DefaultResponse'
      deprecated: false
      security: []  # no authorization for login operation
      externalDocs:
        description: 'API document for business user login'
        url: ''


  # path about repository operations
  /repository:

    summary: 'repository related operations'

    description: 'Operations: create/update/delete/query repository'


    # POST operation
    post:

      # tags for API documentation control
      tags:
        # - 'repository'
        - 'business'

      # short summary about what the operation does
      summary: 'create new repository'

      # verbose explanation of the operation behavior
      description: 'create new repository with certain repository name'

      # Additional external documentation for this operation
      externalDocs:
        description: 'API document for repository creation'
        url: ''

      # unique string to identify the operation
      operationId: 'repositoryCreation'

      # request body,only supported in HTTP
      requestBody:
        $ref: '#/components/requestBodies/repoCreationBody'

      # list of possible responses as they are returned from executing this operation
      responses:
        '200':
          $ref: '#/components/responses/repoCreationResponse'
        'default':
          $ref: '#/components/responses/DefaultResponse'

Command line used for generation

openapi-generator generate -i swagger.yaml -g python -o /tmp/test/python-3

Steps to reproduce

Running the command above is enough.

[jmini]

This is a known issue in my opinion because of the TODO in the code:

openapi-generator/modules/openapi-generator/src/main/java/org/openapitools/codegen/utils/URLPathUtils.java

Line 49 in d42ff75

// TODO need a way to obtain all server URLs

Thank you a lot for this issue, because I think it is important for us to support the most OAS3 concepts we can.

What is the desired result if the yaml contains multiple urls?

The current behavior is to just take the first one in the generated code. I am not saying that it can not be changed...

What do you expect in the generated code?

We also need to consider that it is possible to indicate server url/port with a configuration (I am not sure if this is for all generators or just some of them).

Related to this topic (issue #592), it is also possible to use variables in server definitions:

servers:
- url: https://api.gigantic-server.com:8080/{version}
  description: The production API server
  variables:
    version:
      enum:
        - 'v1'
        - 'v2'
      default: 'v2'

In theory out of the enum value we could generate multiple server URLs...

[developersteve]

Been meaning to add a ticket for this as well, ive got a spec with paths that start with version so was looking to use this to move it into a baseurl and change paths where needed (only it doesnt seem to work at the moment)

[wing328]

UPDATE: we've added better servers support via #816

We'll need to update the templates accordingly.

If anyone wants to help on this, please reply to let us know.

[pecigonzalo]

@wing328 could you provide an example for lets say, python on how to use them(the new vars)? Im willing to update some of them.

[wing328]

@pecigonzalo thanks for offering help. Let me create an example using the Ruby generator. Will keep you posted.