ContributionsMost RecentMost LikesSolutionsUnique 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?