Support endpoint with different responses for different status codes

[eekboom]

This is from a large public sector project where we implement an api.
The open api yaml specifies different response types for response status 200 and 202 (either a search result or a notification that result is not yet available).

When generating rest controller interface for Spring, the openapi-processior blindly uses the model class for the 202 response.
I managed to get it somehow working by configuring the endpoint to use ResponseEntity as return type, but that needs a pretty hacky workaround:

	public ResponseEntity<FooAvailabilityResponse> fooSearchApplicationJson(String fooType, HttpServletRequest request, FooSearchQuery body) {
		FooSearchResult result = FooSearchResult.builder().build();
		ResponseEntity<FooSearchResult> responseEntity = ResponseEntity
				.ok()
				.contentType(MediaType.APPLICATION_JSON)
				.body(result);
		@SuppressWarnings({ "rawtypes", "unchecked" })
		ResponseEntity<FooAvailabilityResponse> rawResponseEntity = (ResponseEntity)responseEntity;
		return rawResponseEntity;
	}

I created a small example project, see https://github.com/eekboom/openapi-processor-example

[eekboom]

BTW: OpenApiTools/openapi-generator handles this by using Object as generic type parameter.
That is fine, I think, even though I wish Java had TypeScript's union types.

[hauner]

yes, that is not so nice. Returning Object shouldn't be hard to do. Maybe a marker interface, like one-of, would be nice.

I played around a bit with result-style: all.

The idea behind this option was to use the success response type and ignore the error responses (which can throw). With all it will return Object as result type from the endpoint method.

This helps in this case too as long as any error response is described....

Unfortunately result-style: all is not fully implemented on the path level which breaks this workaround.

map:
  result-style: all

  paths:
    /foo/{fooType}/search:
     # unfortunately this does not work currently
      result-style: all

The fallback workaround is to exclude the endpoint until I have fixed this.

It is still generating an interface ...ExcludedApi for reference. You can use it as template for manually creating an interface with a working method signature.

map:

  paths:
    /foo/{fooType}/search:
      exclude: true

[hauner]

fixed in 2025.2, it can also generate marker interfaces for the result object if enabled.

Thanks for reporting!