Group APIs by a key set at the RestController level

[guibernardi]

Is your feature request related to a problem? Please describe.

I'm trying to group APIs using a kind of "key" instead of path or package which are the options that I found in GroupedOpenApi.

Describe the solution you'd like

Put this key in an annotation or any points of the API and during the group process I could do something like:

return GroupedOpenApi.builder().group("myGroup").pathsToMatch(GROUP_PATHS).keysToMatch(MY_KEY).build();

Describe alternatives you've considered

I considered create my own annotation which provides an alias for operationId in @Operation and during the Configuration:

@Operation(operationId = "contractpackage/FindOneTestContract.json")

@MyOperation(contract = "contractpackage/FindOneTestContract.json", type = "GROUP_KEY")

Just a test:

	@Bean
	public String testing(RequestMappingHandlerMapping requestMappingHandlerMapping) {
		requestMappingHandlerMapping.getHandlerMethods().forEach((key, value) -> {
			MyOperation myOperation = value.getMethod().getDeclaredAnnotation(MyOperation.class);
			if (myOperation != null) {
				if (myOperation.type().equalsIgnoreCase("GROUP_KEY")) {
					String path = key.getPatternsCondition().getPatterns().toArray()[0].toString();
					GROUP_PATHS.add(path.replaceAll(pathPattern.pattern(), "$1"));
				}
			}
		});
		return "";
	}

So every time I added a new endpoint or API I don't need to change the path variable in Configuration class and this could be isolated at the API level for the developer.

Additional context

In my context I have endpoints separated by two profiles, the most part are: v1/profileName/{profileId}, but I also have commons APIs which could be accessible by both profiles: v1/common and some of them is like v1/otherApi but is accessible only by one profile.

So I have the following patterns:

v1/profileOne/{profileId} -> Grouped by ProfileOne
v1/profileTwo/{profileId} -> Grouped by ProfileTwo
v1/common -> Grouped by Common
v1/otherApi -> Should be grouped in ProfileOne

So if an API resides in the common pattern it should be excluded from profileOne e profileTwo group, the same rule applies to otherApi.

[bnasslahsen]

@guibernardi,

Without adding a custom annotation, you simply:

• Define a @Tag on your operation level with the correct group name or in the @Operation level
  • If you don't want use the tags, then you have other @Operation attributes where you can add your key for search in part of the summary, description or any other relevant fields for your case.
• Then use it for the filtering through OpenApiCustomiser

This is just a sample with tags, that you can adapt.

@RestController
public class HelloController {

	@GetMapping(value = "/sample1")
	@Tag(name = "profileOne")
	public void sample1(String toto) {
	}

	@GetMapping(value = "/sample2")
	@Tag(name = "profileTwo")
	public void sample2(String toto) {
	}

	@Bean
	public GroupedOpenApi groupProfileOne() {
		return GroupedOpenApi.builder()
				.addOpenApiCustomiser(openApiCustomiserProfileOne())
				.group("profileOne")
				.packagesToScan("demo")
				.build();
	}

	@Bean
	public GroupedOpenApi groupProfileTwo() {
		return GroupedOpenApi.builder()
				.addOpenApiCustomiser(openApiCustomiserProfileTwo())
				.group("profileTwo")
				.packagesToScan("demo")
				.build();
	}

	private OpenApiCustomiser openApiCustomiserProfileTwo() {
		return openApi -> openApi.getPaths().entrySet()
				.removeIf(path -> path.getValue().readOperations().stream()
					.anyMatch(operation -> operation.getTags().contains("profileOne")));
	}

	private OpenApiCustomiser openApiCustomiserProfileOne() {
		return openApi -> openApi.getPaths().entrySet()
				.removeIf(path -> path.getValue().readOperations().stream()
					.anyMatch(operation -> operation.getTags().contains("profileTwo")));
	}
}