- 
                Notifications
    
You must be signed in to change notification settings  - Fork 350
 
Description
Why
Currently we reuse/reference the exact same schema for response and requestBody in our OpenAPI specs.
This leads to certain fields/properties being left as optional in the response because in the requestBody they these field shouldn't be sent to the server when using a PUT etc. Examples of common fields being creationTime, modificationTime and kri
For correctness and ease of use for HTTP clients it would be helpful if the response had a different shape to requestBody. response could have fields such as creationTime marked as required and in the requestBody fields such as creationTime could be omitted entirely.
What
The OpenAPI specs should have different response and requestBody to be a correct specification.
We currently autogenerate our OpenAPI specs and from what I understand (without having the context) it is complicated to add something to produce specs directly that have differing response and requestBody.
Therefore as a suggestion, we could try generating the response (as we do now) and instead of referencing the same spec for requestBody we could instead copy the same spec to requestBody.
As requestBody is now a copy we can try using a very small OpenAPI overlay to amend this copy to remove creationTime, modificationTime and kri from requestBody for requestBody for all resources.