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?
