Мне нужно определить два разных определения OpenApi с помощью springdocs для одного и того же API в одном приложении: одно для внутренних разработчиков и одно для внешних разработчиков. Внешнее определение будет включать некоторые операции из внутреннего определения, но не все из них.
Я рассмотрел использование GroupedOpenApi для создания двух определений, но для этого мне необходимо переместить конечные точки, которые должны быть исключены из внешнего определения, в отдельный RestController и перейти в исключенный пакет, который не будет включен в определение для внешнего разработчиков, но все равно будет включено во внутреннее определение. Я бы предпочел структурировать свой код на основе определения API, а не на основе безопасного доступа для моих конечных точек.
Похоже, что либо SecurityScheme, либо теги могут использоваться для определения того, какие операции включены в данное определение, используя что-то вроде GroupedOpenApi с путями / пакетами для включения. Так, например, я мог бы определить определение своего внешнего API примерно следующим образом:
GroupedOpenApi.builder()
.group("externalGroupName")
.securitySchemesToInclude("externalSchemeName") // this doesn't currently exist
.build();
И затем любая из операций, помеченных SecurityRequirement с этой SecurityScheme, будет добавлена к этому внешнему определению. Так, например, у меня могут быть следующие две конечные точки, определенные в одном и том же RestController:
Будет включено:
@SecurityRequirement(name = "externalSchemeName")
@GET
@Path("/pets")
public Response getResponse(){
return null;
}
}
Не будут включены:
@SecurityRequirement(name = "internalSchemeName")
@GET
@Path("/pets/internal")
public Response getInternalResponse(){
return null;
}
}
При таком подходе было бы неплохо предусмотреть схемы безопасности включения / исключения, аналогичные путям / включениям / исключениям пакетов.
Похоже, что в настоящее время потребуется внести вклад в springdocs, если я не понимаю свои варианты создания нескольких определений. Есть ли другой способ добиться исключения операции только из одного из определений, которые я определяю, без полного сокрытия этой операции из всех определений и без реструктуризации моих пакетов?
Обратите внимание, что я также предпочел бы не вести список всех путей, которые должны быть исключены из группы в конфигурации, если это возможно, поскольку это подвержено ошибкам и не позволяет предоставлять общую конфигурацию для нескольких служб. Я бы предпочел метод на основе аннотаций, аналогичный тому, как выполняется другая настройка чванства, чтобы я определял конфигурацию один раз, а затем обновлял каждый ресурс по мере его определения или изменения на основе аннотации, чтобы управлять генерируемым чванством.
