fix: refactor AspectModelAsyncApiGenerator to use AspectModelJsonSchemaVisitor + minor fixes#934
Conversation
…maVisitor + minor fixes
| } | ||
| aspect.getOperations().forEach( operation -> { | ||
| operation.getInput().forEach( input -> | ||
| addOperation( operationsNode, aspect.getName(), input.getName(), ACTION_RECEIVE ) ); |
There was a problem hiding this comment.
This generates an Operation for each input, which is not desirable. Instead, generate only one Operation with an object wrapping all inputs. Also consider adding suffixes to the generated messages like "Request" and "Response"
There was a problem hiding this comment.
Thank you for noticing this, Andreas.
I added a question with example for this case, in related ticket, but now I see that you have mentioned it here.
Just to confirm - you are right that when we have an Operation with 1 or more inputs, all of these should be handled under 1 AsyncAPI Operation as inputs.
Having multiple AsyncAPI operations for each individual input in the Aspect Model Operation is wrong because, in the model we would have defined specific Operation, which takes number of input parameters, that correspond to specific case or are required to be able to provide the declared in the aspect model operation response.
However, splitting the inputs in standalone AsyncAPI operations will break this set up, because it will provide # number of possible AsyncAPI calls that would be expected to return same response, which will be impossible due to the missing other input parameters.
With regards to the "Request" and "Response" - this would be very handy for better readability and understanding of the generated AsyncAPI, when one is going through it.
Thanks again and I hope that this would also be addressed in this fix :)
2 participants
Description
Fixes #928
Type of change
Please delete options that are not relevant.
Checklist:
No docs needed IMO
Additional notes:
Add any other notes or comments here.