| Server Object | N | The servers are not used in request matching. See Issue #28 for background. Comparison of Pact interactions to OAS endpoints does not consider any basePath in its comparison. In OAS 3 (and also 2), all API endpoints are considered to be relative to the base URL. For example, assuming the base URL of https://api.example.com/v1, the /users endpoint refers to https://api.example.com/v1/users. Our comparison does not consider the impact of basePath as there may be multiple servers with different context paths and there is no clear way to resolve this ambiguity. In this example, a pact interaction with path /v1/users/ will not match an OAS that only has /users/ in its resource path. | Example |
| Security Filtering | N | Ignored | |
| Info | N | Ignored | |
| Contact | N | Ignored | |
| License | N | Ignored | |
| External Documentation | N | Ignored | |
| Security Scheme | P | See below for detail. Supports all valid values, only validates only: apiKey | |
| Relative References | Y | | |
| Callbacks | N | Not supported | |
| Parameter styles | P | See also https://swagger.io/docs/specification/serialization/.
Missing parameters will cause a validation warning but not fail the checks
We can’t currently compare non-primitive query string values to the OAS, because Pact does not encode the style of encoding. This means we can’t reliably differentiate the cases where an object or array is encoded. We can check primitive values match the schema.
Where a pact interaction does not satisfy a parameter constraint, you will see a message such as: Path or method not defined in spec file: GET /path/style/simple/single/value/0 (the 0 here does not match the schema, which specifies the value must be > 0) | Example |
| Path parameters | P | Understands primitive parameters, and is able to apply schema validation to primitive data types e.g. restricting values between 1-10 for integers. Does not support array or objects. | Example |
| Query parameters | P | Query parameters are partially supported. If a query parameter used in a consumer test is not defined in the OAS, it will generate a warning. This allows consumers to deploy ahead of providers for certain use cases. | Example |
| Headers | Y | | |
| Bodies | P | Full schema support on JSON bodies only | |
| Status codes | Y | | |
| Link | N | Ignored | |
| Tag | N | Ignored | |
| Example | N | Ignored | |
| Discriminator | P | discriminator usage has the following requirements and limitations: mapping in discriminator object is not supported.- "implicit" discriminator values are not supported.
oneOf keyword must be present in the same schema.discriminator property should be required either on the top level, or in all oneOf subschemas.- each
oneOf subschema must have the properties keyword with discriminator property. The subschemas should be either inlined or - included as direct references (only
$ref keyword without any extra keywords is allowed). - schema for
discriminator property in each oneOf subschema must be const or enum, with unique values across all subschemas. - Not meeting any of these requirements would fail schema compilation.
| |