'What are the advantages of API contracts being consumer driven vs provider driven?
I often read about establishing API contracts, but I'm not sure why it's usually recommended to be consumer driven? Can someone explain what are the advantages/disadvantages of API contracts being consumer driven as opposed to provider driven?
Solution 1:[1]
One advantage of Consumer Driven contract testing is the fact that the consumers control what they need, providers must satisfy the needs of its consumers. This reduces the risks of breaking changes and eliminates coupling. The Provider can not change things that break any of its consumers, and if it does, it must provide backwards compatibility for those consumers else contract testing on the side of the provider will fail and the change will not even make it to production.
Provider driven contract testing gives the control to the provider, and consumers must update when there is a change. This introduces tight coupling between the provider and its consumers.
Solution 2:[2]
I'm Yousaf, A developer advocate here at Pact https://pact.io/ and Pactflow - https://pactflow.io/
We have an open forum about contract testing in our Pact Foundation Slack, you can join over at https://slack.pact.io
We've long been advocates of consumer-driven contract testing but heard the pains it caused providers pains, so we recently delivered a new feature to allow for provider or consumer driven workflows.
I will use the terms CDCT (Consumer Driven) / BDCT (Bi-Directional) Contract testing.
When contract testing with Pact or traditional CDCT, you need to write and maintain a separate set of (Pact) tests that are responsible for ensuring systems are compatible. The tests on the consumer side produce a consumer contract containing the example scenarios which must be supported for the consumer to work, which are then replayed against an actual running provider in a record and replay style interaction. If the Provider responds correctly, the contract is valid.
With BDCT, the key difference is that a Provider uploads its own provider contract advertising its full capability which is statically compared to the expectations in the consumer contract - the consumer contract is never replayed against the provider code base. This creates a much simpler and decoupled workflow. See the trade-offs for more.
BDCT is not intended to replace Pact/CDCT testing, but to provide an alternative in the cases where Pact/CDCT may not be best suited.
You can see a table of use cases here which should hopefully help describe some of the various scenarios
https://docs.pactflow.io/docs/bi-directional-contract-testing#comparison-to-pact
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | yhiamdan |
| Solution 2 | YOU54F |