Generated OpenAPI behaves differently in Hoppscotch: Why?

[cristalp]

We use Smallrye in two separate scenarios: In our JEE development chain and in the Quarkus development chain.

However, we noticed that importing the OpenAPI definition into Hoppscotch is different.

First, Quarkus, which works perfectly. Apparently we use Smallrye 3.15.3.1, which generates OpenAPI 3.0.3. I import this into Hoppscotch and have to add ?format=json to the URL for Hoppscotch to work.

Without having to do anything, every endpoint shows me that it's expecting a variable <<baseUrl>>.

All I have to do is import a Postman environment file, which is generated automatically by our build environment. And then everything works great out of the box!

However, in our JEE toolchain, we use the smallrye-open-api-maven-plugin with version 4.0.4, which generates OpenAPI 3.1.0.

When I import this into Hoppscotch, no <<baseUrl>> is added:

So I would have to go and add the <<baseUrl>> to each and every endpoint, and frankly, I have better things to do with my life ;-)

Now the big question is: What's the difference? I don't see anything called baseUrl in any of the two JSON files. Can anyone give me a hint what part of the JSON triggers this behavior?

[MikeEdgar]

Do you know why it's using the prefix /gebuehr-service on that endpoint? Is that part of the OpenAPI from smallrye 4.0.x, but not 3.x?

[cristalp]

It's always great to have someone with an analytical mind at hand :-)

You're right! If I remove the servers, Hoppscotch shows <<baseUrl>> right away.

Ok, so I admit that (if I recall correctly) this crutch of defining a "server" to have the web context was born out of necessity.
Probably not such a good idea... But how could we accomplish this is a good way? I mean, the /gebuehr-service would have to be added as a prefix to every endpoint.

[MikeEdgar]

I mean, the /gebuehr-service would have to be added as a prefix to every endpoint.

Basically, yes. You could could do that with an OASFilter pretty easily.

[cristalp]

Ok, I don't know that part of Smallrye... Is this done at build time or is this a runtime thing?

From what I see online, it looks like runtime. Unfortunately, only a small part of our software runs with Quarkus. The majority is on JBoss EAP 7.4 and even Java 8.

[MikeEdgar]

With Quarkus it (an OASFilter) can execute either at build time or run time, but with EAP it would execute at run time.

You could have something like this:

    @Override
    public void filterOpenAPI(OpenAPI openAPI) {
        openAPI.getPaths().setPathItems(openAPI.getPaths().getPathItems().entrySet().stream().map(e -> {
            return Map.entry("/prefix" + e.getKey(), e.getValue());
        }).collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue)));
}

[cristalp]

Ok, but that wouldn't be reflected within the OpenAPI, and Hoppscotch would show a wrong URL.

Is there no way I can influence the Smallrye Maven plugin to manipulate the path at build time?

[MikeEdgar]

Well, the Maven plugin will run that filter at build time. I overlooked mentioning that part. You could run the plugin twice if you wanted, once with the filter and once without, if that helps (?)

[cristalp]

Ah ok, thanks! I will have to experiment with that.

I would have to give the prefix to the OASFilter at build time. That prefix is kept within a Maven property. Do you have any suggestion how this could be done?

[MikeEdgar]

You can set systemPropertyVariables in the plugin configuration and retrieve them in the filter.