Forum Discussion

gerlowskija's avatar
gerlowskija
Regular Visitor
8 months ago

Unique Operation IDs for APIs using JAX-RS sub-resources

TL;DR - is there any way to have more control over the 'operationId' given to operations in an OAS,  when those APIs are implemented using JAX-RS's "subresource" feature.

 

----

I work on an open source Java project called Apache Solr that is trying to generate an OAS out of some existing JAX-RS and Swagger annotations.  In Solr we have certain chunks of functionality that we offer from two slightly different paths, e.g. GET /collections/{name}/schema and GET /cores/{name}/schema.

 

We represent this succinctly using JAX-RS "sub-resources", as in the snippet below:

 

@Path("/collections/{name}/schema")
public interface GetCollectionSchemaApi {
@Path("/") GetSchemaApi get();
}

@Path("/cores/{name}/schema")
public interface GetCoreSchemaApi {
@Path("/") GetSchemaApi get();
}

public interface GetSchemaApi {
@GET
@Path("/name")
@Operation(...)
SchemaNameResponse getSchemaName();

// Definitions of other shared subpaths omitted here for brevity
}

 

'swagger-gradle-plugin' reads these annotations and produces an OAS that is great in all respects, except that a numeric suffix is used to individuate the operationId of each of these similar APIs.  e.g.

    "/collections/{name}/schema/name" : {
        "get": {
             "operationId": "getSchemaName", ...
        }
    },
    "/cores/{name}/schema/name" : {
        "get": {
             "operationId": "getSchemaName_1", ...
        }
    }

 

We use our OAS for code generation and these "_#" operationId suffixes are less than ideal in our generated code.  Is there any way to influence how 'operationId's are picked and individuated for "@Operation" annotations in JAX-RS subresources.  Or a way to work around these slightly wart-y operationIds when doing code generation?

No RepliesBe the first to reply