[REQ] [JAXRS] Disable common path handling and type level annotations

[danielhodder]

Is your feature request related to a problem? Please describe.

Currently the JaxRS generator differs from a lot of other generators in the Java space (JavaSpring, and Java, specifically) in how it handles top-level paths. In my case I have a base path under which all my API endpoints are hosted. But this path is not actually part of the API since the API could be hosted at different context paths. This means my API definition contains only top-level paths.

paths:
  /foo:
    get: ...
  /bar:
    get: ...

With other generators I get a DefaultApi or similar class with all my bindings in it. From The JaxRS generator (in interface mode) I get an interface for each of these.

The one-type method is fine, except, that the common path is extracted into a type level annotation. So I end up with java types like:

@Path("/foo")
interface FooApi {
    @GET
    public void get();
}

@Path("/bar")
interface BarApi {
    @GET
    public void get();
}

This seems sensible but it means I need to have two different JaxRS resource classes. I can not have a single resource that implements both interfaces since that would loose the type-level binding, and at least in Jersey 1 (which we are using) causes a binding failure.

Describe the solution you'd like

I would like an option which allows me to disable the common-path behavior outright. Basically I would like all my @Path annotations to be on the methods, not on the types. So in the example above:

interface FooApi {
    @GET
    @Path("/foo")
    void getFoo();
}

interface BarApi {
    @GET
    @Path("/bar")
   void getBar();
}

Which means I can then implement a resource class like:

@Path("/")
class Resource implements FooApi, BarApi {
    @Override
    public void getFoo() {}

    @Override
    public void getBar(){}
}

For compatibility such an option should default to doing the same thing it has always done but this would be a very useful option for me. In our environment the JaxRS Server is a very thin layer over business services, and we tend to have a lot of 'top-level' endpoints. This would reduce the number of overall classes we have to write, and bind into the container.

One downside of this approach is that do do have to have a type-level @Path annotation somewehere. In my case I put it on the resource that I'm implementing.

Describe alternatives you've considered

I can override the api and apiInterface templates to get the behavior that I want but that means I am now maintaining those as well as just using the generator which is not ideal.

Additional context

[mancusi]

Just commenting to say that I'd also like this! We run into the same limitations in our projects.

[danielFesenmeyer]

Would also be quite useful for implementing Keycloak REST API extensions.