This repository was archived by the owner on Mar 16, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 16, 2025. It is now read-only.
better response type handling #68
Description
If an api has multiple response content types (success & errors) the java response type of the controller method will be Object to allow return values with different java types.
If the errors are handled by throwing an exception there is no need to have an Object response and the controller method could use the type of the success response to improve readability of the interface.
mapping could be like this, using a globally applied option:
# mapping.yaml
openapi-processor-mapping: v2
options:
response-type: all # all (default) or successor like this, allowing endpoint & endpoint/method configuration:
# mapping.yaml
openapi-processor-mapping: v2
map:
response-type: all # all (default) or successall: consider all response types to select the method return type
success: consider only the success response type, i.e. usually 200
Activity
JonasGroeger commentedon May 29, 2021
In the Spring module this is also annoying since even if you put
it will generate
ResponseEntity<?>and notResponseEntity<SuccessResponse>.Could you give me some hints on how you would implement it? I'm willing to write an implementation.
Reference: https://docs.openapiprocessor.io/spring/2021.3/mapping/result.html
global mapping option, #68
hauner commentedon May 30, 2021
Yes, I think that has the same cause.
Thanks for the offer to help -)
Here are a few notes to get you started.
I did a few lines on this to get the new option but that's just a minimal start that does not yet do anything. It is on this branch: https://github.com/openapi-processor/openapi-processor-core/tree/response-type-handling
Current idea is to replace the return type of the controller method in the
MethodWriterhere:openapi-processor-core/src/main/kotlin/io/openapiprocessor/core/writer/java/MethodWriter.kt
Line 47 in e25f7ab
This is the line that adds the response type to the method. Replacing
${endpointResponse.responseType}with a method that does select the return type based on the new option should solve the issue. If the new option isalluse the current behaviour if it issuccessuse the success response type and ignore the error responses.The code to get the wanted type exists and is currently private in the
EndpointResponse:openapi-processor-core/src/main/kotlin/io/openapiprocessor/core/model/EndpointResponse.kt
Line 37 in e25f7ab
Note that the identical selection is required to create the import list.
Getting that option is probably the harder part. Converting the
mapping.yamlto the internal format requires a couple of steps and is more complex than I like.If the options is configured like this
the
MethodWriterwill need theMappingFinderto get access to it and then call a similiar function toopenapi-processor-core/src/main/kotlin/io/openapiprocessor/core/converter/mapping/MappingFinder.kt
Line 122 in e25f7ab
The
maps:part of themapping.yamlis converted internally toMappings. TheMappingFinderuses them to find & select mappings.The new option will need a new implementation of the Mapping interface: https://github.com/openapi-processor/openapi-processor-core/blob/response-type-handling/src/main/kotlin/io/openapiprocessor/core/converter/mapping/Mapping.kt
Converting the yaml to the
Mappinghappens here:https://github.com/openapi-processor/openapi-processor-core/blob/response-type-handling/src/main/kotlin/io/openapiprocessor/core/processor/mapping/v2/MappingConverter.kt
I hope this helps and i didn't miss any annoying detail that breaks this approach :)
hauner commentedon May 30, 2021
collecting the import happens here
openapi-processor-core/src/main/kotlin/io/openapiprocessor/core/writer/java/InterfaceWriter.kt
Line 65 in e25f7ab
global mapping option, #68
read option & improve name, #68
want to use option value, #68
avoid string matching, less casting, #68
simpler, #68
extract/migrate to better home, #68
hauner commentedon Jun 6, 2021
@JonasGroeger Hi, I have it nearly running.... I hope you didn't waste to much on on it.
not the place to handle default fallback, #68
simpler access to option mapping, #68
handle response style, #68
update/extend multi response test case, #68
JonasGroeger commentedon Jun 6, 2021
Please don't feel obligated to implement something just because somebody wants it. It's open source after all.
In case you didnt: all good ;)
hauner commentedon Jun 6, 2021
It something I like to see myself :-) A colleague mentioned it and then your comment on the issue. Funny is, that it all happend in a couple of days. ;-)
update mapping json schema, #68
update example, #68
regenerate flat mapping json schema, #68