Support relative server URL

[cbornet]

Description

Generator doesn't support relative URL for OAIv3 servers.
Whereas the spec specifies

This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the OpenAPI document is being served.

openapi-generator version

3.0.1

OpenAPI declaration file content or url

OpenAPI petstore's server URL is relative and it's /v3

Steps to reproduce

• Start the docker petstore on port 8080
• Generate the spring-cloud client
• The default URL in PetApiClient should be http://localhost:8080/v3 but it's http://localhost/v3

[jmini]

See also discussion in #239

---

In my opinion this is the responsibility of the parser to convert the server value into an absolute URL, because when OpenAPI-Generator consumes the OpenAPI there is no indication where it was generated from.

This code snippets already show that the parser does not resolve the server value correctly:

String inputSpec = "http://localhost:8090/openapi.json";

OpenAPIParser openApiParser = new OpenAPIParser();
ParseOptions options = new ParseOptions();
options.setResolve(true);
options.setFlatten(true);

OpenAPI openAPI = openApiParser.readLocation(inputSpec, null, options).getOpenAPI();
String string = Yaml.mapper().writerWithDefaultPrettyPrinter().writeValueAsString(openAPI);

System.out.println(string);

The value stays unchanged. I have filed swagger-api/swagger-parser#742 for that.

[jmini]

The issue in Swagger-Parser was fixed, and with PR #696 OpenAPI-Generator was updated to use a version containing the fix.

This issue reported here, should no longer appear with the newest 3.2.0-SNAPSHOT version.
@cbornet, can you check it?

[rtfeldman]

I'm not sure if I understand correctly, so I wanted to check:

Is the intended design that it is impossible to end up with a generated client which uses relative URLs?

For example, should the following HTTP request be impossible to generate?

GET "/about"

...and should it instead have to be an absolute URL?

[tarioch]

I have the same use case as #1290 (api deployed with the project that consumes the api) and it looks weird to me to fix this on the individual generator basis, should this be something to be fixed generally (maybe simply allowing to override the base path?)