Introduction of message traits

[thompson-tomo]

To foster reusage and adoption of standards/conventions it would be helpful if we could define traits which can be applied to both request's & response's.

A trait could include

• Headers
• Body properties

An example of a trait could be

• Problem details
• Cloud events

These traits can be defined directly in the openapi doc or alternatively sourced from a server.

[handrews]

@thompson-tomo it is possible to do sometihng like this now with the Overlay Specification.

[thompson-tomo]

Agree overlay could help expecially when the trait is user defined however for standardised traits like those mentioned above it. In fact it seems counter intuitive to need to redefine the standardised collection of headers & properties.

If we take an example of a problem detail being returned a developer looking at the rendered spec doesn't easily know what the body properties would contain as they only have the content type to go off. What happens if the author has extended the problem details with additional properties which varies by endpoint/status code.

[handrews]

@thompson-tomo presumably they have provided schemas for their problem detail extensions. Plus the problem details format itself includes fields intended to link to supplementary information.

[thompson-tomo]

Yes that would be the case that extensions can be defined by the user and the trait would work just like the overlays.