Experiments with templated hosts
See original GitHub issueOn the TDC call today, we experimented with a few different options for enabling parameterized host, schema and basePath. Community feedback would be much appreciated.
Option 1: Global parameters are back
{
"openapi" : "3.0.0",
"parameters" : {
"version" : {
"in" : "basepath",
"default" : "v1.0",
"schema" : {
"type" : "string"
}
},
"environment" : {
"in" : "host",
"required" : true,
"schema" : {
"type" : "string"
}
}
},
"hosts" : [
{
"host" : "{environment}.example.org",
"basePath" : "/{version}/api",
"scheme" : "https"
}
]
}
This is a minimally intrusive option but it brings the parameters
back at the global scope which we are not particularly keen to do.
The next option trades the current array of hosts
into a server
object so that it can contain the host
related parameters. It also means that there is only one baseUrl, but it can be parameterized and in fact the entire thing could be a parameter, which could allow for multiple static values using an enum parameter.
{
"openapi" : "3.0.0",
"server" : {
"baseUrl" : "{scheme}://{environment}.example.org/{version}/api",
"parameters" : [
{
"name" : "scheme",
"in" : "host",
"default" : "https",
"schema" : {
"type" : "string"
}
},
{
"name" : "version",
"in" : "host",
"required" : false,
"default" : "v1.0",
"schema" : {
"type" : "string"
}
},
{
"name" : "environment",
"in" : "host",
"required" : true,
"schema" : {
"type" : "string"
}
}
]
}
}
There are concerns about how default
values work in these parameters and the "in" : "host"
is redundant but there just for consistency with the parameter object definition.
Issue Analytics
- State:
- Created 7 years ago
- Comments:13 (11 by maintainers)
Top GitHub Comments
Open 3.0 does have path item parameters, which is a bit less redundant than operation parameters, but still a little annoying. How do you feel about defining a parameters object inside a hosts/server object?
Since #812 was merged, I’m closing this out.