Skip to content

Multiple OpenAPI definitions in one Spring Boot project #213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hemju opened this issue Dec 2, 2019 · 17 comments
Closed

Multiple OpenAPI definitions in one Spring Boot project #213

hemju opened this issue Dec 2, 2019 · 17 comments
Labels
enhancement New feature or request

Comments

@hemju
Copy link

hemju commented Dec 2, 2019

I am trying to describe two different versions (v1 and v2) with Open API. Basically Swagger UI I should display v1 from http://localhost:8080/v3/api-docs and v2 from http://localhost:8080/v3/api-docs/v2.

With the springfox Swagger Config I could do this through Dockets. Then I had the selection where I could switch the different endpoint definitions.

@springdoc
Copy link
Collaborator

The library generates one OpenAPI definition per spring-boot application.
We do not expose the /v3/api-docs endpoint, many time for the same application.

@hemju
Copy link
Author

hemju commented Dec 4, 2019

@springdoc please don't close the issue right away, because even if you don't allow multiple OpenAI definitions, there is still the question on how to document different versions. Like Springfox Swagger Config allowed with Docket. So can you please tell me if that is possible or not. And if it is possible on how to achieve that. Because I went through the documentation and I only found one way to document all different versions (in our case v1, v2 and internal).

@tvahrst
Copy link

tvahrst commented Dec 4, 2019

We have the same requirements. We currently try to find a 'non-invasive' solution on top of springdoc to allow the definition of multiple APIs - possibly by adopting the Docket-concept from Springfox and replacing/deactivating the main Controller (OpenApiResource). Nevertheless, we would be happy if sprindoc allowed native support for multiple API Definitions... ;-)

@springdoc
Copy link
Collaborator

Hi guys,

You can disable the springdoc endpoints using configuration property.
If you are achieving the Docket concept, you can propose a pull request and it will be added.

@hemju
Copy link
Author

hemju commented Dec 4, 2019

We have the same requirements. We currently try to find a 'non-invasive' solution on top of springdoc to allow the definition of multiple APIs - possibly by adopting the Docket-concept from Springfox and replacing/deactivating the main Controller (OpenApiResource). Nevertheless, we would be happy if sprindoc allowed native support for multiple API Definitions... ;-)

Thomas, could you please share you approach on how you do it. Because I think that many people have a similar requirement

@tvahrst
Copy link

tvahrst commented Dec 5, 2019

Sure. This is 'work in progress'. If we find a solution, we will share it.

@dan-whitehouse
Copy link

I just wanted to comment and say that I also require this. The only reason I haven't switched over to spring-doc is the lack of support for this feature.

I have 1 application with 2 totally different data models. It makes little sense for both of them to appear in the same Swagger UI . Nor does it make sense for me to have to make a totally separate application and maintain the shared components.

@sfauvart
Copy link

sfauvart commented Dec 9, 2019

Hello, I don't know if it can resolve your problem but you can use the springdoc.swagger-ui.config-url and make a restcontroller endpoint to generate a json with your multiple api-docs urls as is it described in swagger documentation.
I used them for a microservice gateway.

@tvahrst
Copy link

tvahrst commented Dec 10, 2019

Hi, here a short summary of our attempt do build multi-api support on top of springdoc:

We have a good idea how to map operations (i.e. RestController methods ) to specific OpenAPIs. We build a kind of filter class to define URL and package patterns for every specific OpenAPI (similar to springfox 'Dockets').

But we do have problems with all the possible options to define OpenAPI main attributes, like info, security... For example, it's currently possible to provide a OpenAPI bean as Spring bean, which acts as 'template' for the finally generated OpenAPI. Additionally, it's possible to annotate an arbitrary bean with @OpenApiDefinition (from Swagger) and define for example info attributes. These are global definitions which would apply to all specific OpenAPI Definitions. Finally, springdoc's OpenAPICustomizer is a global customizer and has currently no support for multiple different OpenAPIs

Our idea is to provide additional possibilities to declare OpenAPI properties for specific OpenAPI definitions, which then will override the aforementioned global definitions.

A second challenge is the implementation of OpenAPIBuilder. This is a spring bean (singleton) and references the resulting OpenAPI object during the build-phase and afterwards as 'holder' of the OpenAPI object. As we need multiple OpenAPI objects, we cannot use this singleton bean, but have to create mulitple OpenAPIBuilder instances (for every specific OpenAPI). But there are other spring-beans referencing OpenAPIBuilder, like OperationBuilder which in turn is referenced by RequestBuilder and ResponseBuilder. For all these classes we need multiple instances because they (in-)directly reference OpenAPIBuilder (which holds the OpenAPI object).

(BTW: It would be nice if the class SecurityParser was public. Currently we need ugly reflection tricks to instantiate OperationBuilder, which needs the SecurityParser instance).

This is our 'current score'. Our solution so far is far away from being ready and does not seem to become a good 'open-source candidate' for a pull request ;-) For example, we did not focus on WebFlux support or support for Kotlin Coroutines, as we do not need these features.

@springdoc
Copy link
Collaborator

springdoc commented Dec 17, 2019

This feature will be available on the next release: v1.2.19 of springdoc-openapi.

You can define your own groups of API based on the combination of: API paths and packages to scan. Each group should have a unique groupName.
The OpenAPI description of this group, will be available by default on:

To enable this feature, the following springdoc property needs to be added to your application.yml:

springdoc.api-docs.groups.enabled=true

For the support of multiple OpenAPI definitions, a bean of type GroupedOpenApi needs to be defined.

For the following Group definition(based on package path), the OpenAPI description url will be : /v3/api-docs/stores

@Bean
public GroupedOpenApi storeOpenApi() {
	String paths[] = {"/store/**"};
	return GroupedOpenApi.builder().setGroup("stores").pathsToMatch(paths)
			.build();
}

For the following Group definition (based on package name), the OpenAPI description url will be: /v3/api-docs/users

@Bean
public GroupedOpenApi userOpenApi() {
	String packagesToscan[] = {"test.org.springdoc.api.app68.api.user"};
	return GroupedOpenApi.builder().setGroup("users").packagesToScan(packagesToscan)
			.build();
}

For the following Group definition(based on path), the OpenAPI description url will be: /v3/api-docs/pets

@Bean
public GroupedOpenApi petOpenApi() {
	String paths[] = {"/pet/**"};
	return GroupedOpenApi.builder().setGroup("pets").pathsToMatch(paths)
			.build();
}

For the following Group definition (based on package name and path), the OpenAPI description url will be: /v3/api-docs/groups

@Bean
public GroupedOpenApi groupOpenApi() {
	String paths[] = {"/v1/**"};
	String packagesToscan[] = {"test.org.springdoc.api.app68.api.user", "test.org.springdoc.api.app68.api.store"};
	return GroupedOpenApi.builder().setGroup("groups").pathsToMatch(paths).packagesToScan(packagesToscan)
			.build();
}

For more details about the usage, you can have a look at the following sample Test:

@dpak-github
Copy link

dpak-github commented Jul 30, 2020

Is it possible to redirect to swagger-ui on different port number using GroupedOpenApi? I'm looking for spring fox SwaggerResourcesProvider alternative. I want to choose a spec for each of my microservice and redirect to that URL without using RouteDefinition etc.

@kanai0618
Copy link

So, when i do /v3/api-docs/, i can see all the endpoints , and when i do /v3/api-docs/stores , i can see store related. how do i stop /v3/api-docs/, to not to show anything ?

@bnasslahsen
Copy link
Collaborator

Is it possible to redirect to swagger-ui on different port number using GroupedOpenApi? I'm looking for spring fox SwaggerResourcesProvider alternative. I want to choose a spec for each of my microservice and redirect to that URL without using RouteDefinition etc.

If you use the actuator management port, it's possible to have access to the swagger-ui using the actuator port instead.

@bnasslahsen
Copy link
Collaborator

So, when i do /v3/api-docs/, i can see all the endpoints , and when i do /v3/api-docs/stores , i can see store related. how do i stop /v3/api-docs/, to not to show anything ?

There is no such a setting.
You seem to be the first one to have this requirement.
You can log a new enhancement request or directly propose a PR which adds a property to disable this endpoint for your case.

@kanai0618
Copy link

Thanks @bnasslahsen , i was able to fix it. one thing i want to know, i have url eg: /internal/abc , and in swagger i want to show /abc , instead of parsing the url, is there any other better way to solve this ? like all /internal i want to trim it and dont show /internal.

@ToppScorer
Copy link

From which endpoint can I download a YAML file for a group?

@ToppScorer
Copy link

From which endpoint can I download a YAML file for a group?

Answering myself here: http://server:port/context-path/v3/api-docs.yaml/groupName

@springdoc springdoc locked as resolved and limited conversation to collaborators Apr 23, 2021
@bnasslahsen bnasslahsen added the enhancement New feature or request label Jan 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

8 participants