Skip to content

Support endpoint with different responses for different status codes #328

Closed

Description

@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

Activity

  1. eekboom commented on Mar 20, 2025

    @eekboom
    Author

    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.

  2. hauner commented on Mar 20, 2025

    @hauner
    Member

    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
  3. added this to the core: next milestone on Mar 25, 2025
  4. modified the milestones: core: next, 2025.2 on Apr 4, 2025
  5. hauner commented on Apr 21, 2025

    @hauner
    Member

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

    Thanks for reporting!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions