A component that initiates a HTTP request to another component (the service
Provider). Note that this does not depend on the way the data flows - whether it is a
GET or a
Consumer is the initiator of the HTTP request.
A server that responds to an HTTP request from another component (the service consumer). A service provider may have one or more HTTP endpoints, and should be thought of as the "deployable unit" - endpoints that get deployed together should be considered part of the same provider.
Mock Service Provider
Used by tests in the
Consumer project to mock out the actual service
Provider, meaning that integration-like tests can be run without requiring the actual service
Provider to be available.
A request and response pair. A pact consists of a collection of
A file containing the JSON serialised
interactions (requests and responses) that were defined in the
Consumer tests. This is the
Contract. A Pact defines:
- the consumer name
- the provider name
- a collection of interactions
- the pact specification version (see below)
To verify a
Pact, the requests contained in a
Pact file are replayed against the
Provider code, and the responses returned are checked to ensure they match those expected in the
A name describing a “state” (like a fixture) that the
Provider should be in when a given request is replayed against it - e.g. “when user John Doe exists” or “when user John Doe has a bank account”. These allow the same endpoint to be tested under different scenarios.
A provider state name is specified when writing the
Consumer specs, then, when the pact verification is set up in the
Provider the same name will be used to identify the set up code block that should be run before the request is executed.
Consumer connecting to a Scala JVM-based
Provider) , using semantic versioning to indicate breaking changes.
Each language implementation of Pact needs to implement the rules of this specification, and advertise which version(s) are supported, corresponding closely to which features are available.