Based on the operation info the content type is determined. If it is
FORM_URLENCODED, it is handled differetly, because of the specification
requirements.
The support is naive because a definition is created (as in the old
behavior), but rather pointing to a reference to that definition.
I am shallowly recursing through it and mapping it to a formData
dictionary.
A better solution is to extend the visitor pattern when creating
definitions and a support for FORM_URLENCODED, rather than creating
an unused definition. But, since this is a large effort, the naive
solution seems suitable.
Added tests and compared old and newly generated specifications.
Based on the operation info the content type is determined. If it is FORM_URLENCODED, it is handled differetly, because of the specification requirements.
The support is naive because a definition is created (as in the old behavior), but rather pointing to a reference to that definition. I am shallowly recursing through it and mapping it to a formData dictionary.
A better solution is to extend the visitor pattern when creating definitions and a support for FORM_URLENCODED, rather than creating an unused definition. But, since this is a large effort, the naive solution seems suitable.
Added tests and compared old and newly generated specifications.
NOTE - support only for swagger 2.0
Signed-off-by: Anton Obretenov obretenova@vmware.com