The current Pact Specification stores query parameters as maps (change introduced in v3 of the spec).
This change made it impossible to infer the various styles of real world query string usage, as the serialisation format is not stored in the contract.
For example, given the following query section from a pact:
"foo": ["bar", "baz"]
A client has at least 2 common choices in how to send this:
/?foo=bar&foo=baz
and
/?foo[]=bar&foo[]=baz
It's unclear (i.e. the spec doesn't define) what format the verifier would send the query string in during verification.
It gets more complicated with nested objects, something that is common in APIs that have complex queries encoded as query strings instead of body (see e.g. GraphQL)
One approach would be to allow the test author to specify the encoding style for use by the mock server and verifier.
OpenAPI has a system capable of modelling the various behaviours, this could be a good starting point.
The current Pact Specification stores query parameters as maps (change introduced in v3 of the spec).
This change made it impossible to infer the various styles of real world query string usage, as the serialisation format is not stored in the contract.
For example, given the following
querysection from a pact:A client has at least 2 common choices in how to send this:
and
It's unclear (i.e. the spec doesn't define) what format the verifier would send the query string in during verification.
It gets more complicated with nested objects, something that is common in APIs that have complex queries encoded as query strings instead of body (see e.g. GraphQL)
One approach would be to allow the test author to specify the encoding style for use by the mock server and verifier.
OpenAPI has a system capable of modelling the various behaviours, this could be a good starting point.