[OAS 3.0.0] yaml with multiple server urls generates code using first url only
See original GitHub issueDescription
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.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:4
- Comments:8 (6 by maintainers)
Top Results From Across the Web
OpenAPI Specification - Version 3.0.3 - Swagger
The OpenAPI Specification defines a standard interface to RESTful APIs which allows both humans and computers to understand service capabilities without ...
Read more >OpenAPI Specification v3.0.3 | Introduction, Definitions, & More
The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs.
Read more >Step 3: The servers object (OpenAPI tutorial)
Paste the servers object (the first code sample above showing just one url ) into your Swagger Editor, adding to the code you...
Read more >RESTful APIs: Tutorial of OpenAPI Specification - Medium
We also shortly go over the ways to generate code for client and server. The examples in this article are in YAML but...
Read more >API import restrictions and known issues - Azure
0 (import only). HTTPS URLs. If multiple servers are specified, API Management will use the first HTTPS URL it finds. If there aren ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This is a known issue in my opinion because of the TODO in the code:
https://github.com/OpenAPITools/openapi-generator/blob/d42ff75cebeb7d7aab80f4b48e6a77f3ac5e489a/modules/openapi-generator/src/main/java/org/openapitools/codegen/utils/URLPathUtils.java#L49
Thank you a lot for this issue, because I think it is important for us to support the most OAS3 concepts we can.
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:
In theory out of the enum value we could generate multiple server URLs…
@wing328, would be possible to set some parameter at command prompt to override values in model’s server variable ?