Pact Foundation

Hi all

Just a question regarding Open API spec.

I have a situation in which the schema of the response varies depending on a parameter in the request. That parameter in the request is an enum and for each value there is a different response schema.

Is there a way to model that on an Open API spec.

My ultimate goal is to use that spec in a  Bi-Directional contract test.

Regarding the OAS, I don't believe there's a way to map responses to request fields (e.g. response A if enum A, response B if enum B). As far as I know, the closest thing is `oneOf`

My investigations so far led me to believe that was the case.

But I was hopeful someone might have a nifty solution.

Looks like I will have to resort to traditional Pact for those interactions.

I wonder if a "regular" consumer-driven contract test, where the provider itself verifies, would be better if needing to do this sort of thing

This is one of the problems with OAS and schemas in general, see also <https://pactflow.io/blog/schemas-are-not-contracts/|https://pactflow.io/blog/schemas-are-not-contracts/>

You can model polymorphic payloads but you can't say the conditions that lead to them.

In practice, they're likely not to vary in unexpected ways (i.e. if there is a 1:1 mapping of enim value to schema then it's unlikely to change once stable) so you could still use an OAS with a oneOf 

Otherwise Pact has got you covered

Thanks Matt.

I will have to use consumer-driven contract testing for this, as for the same endpoint there are effectively multiple combinations of request/response, and there is currently no way of modelling that in OAS.

A side question <@U9UUY3CU9>

Is there a plan to expand Bi-Directional CT for asynchronous interactions ?

&gt; I will have to use consumer-driven contract testing for this, as for the same endpoint there are effectively multiple combinations of request/response, and there is currently no way of modelling that in OAS.
Just so we’re clear. In OpenAPI you _can_ model different input/output shapes - that’s achieved through polymorphisms (e.g. `anyOf`, `oneOf` and `allOf`). What you can’t describe in an OAS is “if I get this _input_, then I should send this specific _output_). You can say “These are the allowed inputs” and “these are the allowed outputs”

&gt; Is there a plan to expand Bi-Directional CT for asynchronous interactions ? (edited)
eventually, yes. What use case do you have (to help us prioritise)?

The problem with polymorphism is that I don't have a discriminator to use on the response. And my case is exactly: if I get this _input_, then I should send this specific _output"._

My use case is two services communicating via a kafka.

I would like to use something like AsyncAPI for the provider contract.

For consumer contracts I can programatically create Pacts by using the kafka messages that are generated as part of the service functional tests.

awesome, thanks for sharing. Kafka + AsyncAPI is something we’d like to support