This document discusses different approaches to developing APIs between provider and consumer teams: provider-driven, contract-driven, and consumer-driven. In a consumer-driven approach, the provider and consumer teams meet briefly to agree on the basic API structure. Then, the consumer team iteratively builds expectations and shares them with the provider team. The provider team then iteratively builds the API and verifies it meets the expectations. This approach is good when needs are not fully known, consumers are limited and known, and fast integration with feedback is desired. Challenges include needing tools to facilitate and both teams having to work test-driven and share expectations iteratively.

1. Consumer driven
contracts
The evolution of your APIs
supported by tests
wemanity
@nelisboucke
@matteo_pierro

2. A typical situation
• Several teams in a company need to integrate an API
• New functionality
ProviderConsumer
Consumer
Contract
…

3. How does the cooperation go?

4. Provider driven
• Provider builds API as they see fit
• Often just expose all info
• Consumer starts when provider is ready
Provider
Contract
Consumer
Consumer
…

5. Challenges for in our situation
• Often too complex to achieve normal flows
https://upload.wikimedia.org/wikipedia/commons/thumb/d/d6/STS120LaunchHiRes-edit1.jpg/1024px-STS120LaunchHiRes-edit1.jpg

6. Challenges for in our situation
• Ping-pong to make it work
• Never perfect fit for consumers
• Lots of waiting, bugs, interrupts to test, …

7. Challenges for in our situation
• Late feedback from end users

8. Good for
• API is (part of) the product
• Lots of (unknown) consumers
• many opportunities to collect feedback
• Budget for multiple iterations on the API

9. Contract driven
• Meeting to agree on the complete API in advance
• Build in parallel, use mock or stub
• Integrate at the end
Provider
Contract
Consumer
Consumer
…

10. Challenges in our situation
• Analysis paralysis + Contract negotiation over cooperation!

11. Challenges in our situation
• Most of the time details where not agreed on, so still mismatches

12. Challenges in our situation

13. Challenges in our situation
• Integration near deadline

14. Good for
• When you know what you need
• e.g integration with existing system and datamodel
• Working with a (external) party where you want to protect yourself
• At least it is clear what to expect

15. Consumer driven
• Short meeting to agree on basic structure of API
• Consumer iteratively builds + shares expectations
• Provider iteratively builds + verifies with expectations
Provider
Contract
Consumer
Consumer
…

16. Why is it good in our situation?
• You do not exactly know what you need
• Limited and known consumers
• You want to integrate fast
• Fast feedback
• Reduce integration risk

17. Challenges
• Tools needed to make it easier

18. Challenges
• Provider needs to adapt WoW to incorporate consumer changes

19. Challenges
• Consumer needs to work test driven and share expectations

20. Who are we?
Nelis Boucké Matteo Pierro
@nelisboucke
@matteo_pierro

21. Overview of Pact way of working

25. Topics to discuss?
• VS swagger and wire mock?
• What if something goes wrong?
• Demonstrate how works with CI in this case
• Versioning?
• Challenges on implementing this in your team(s)?
• Way of working a provider side?
• Incident?