This document discusses approaches for managing API evolution and compatibility. It recommends using consumer-driven contract testing to decouple development lifecycles. It also suggests preserving API compatibility by avoiding breaking changes and verifying compatibility using tools like Spring Cloud Pipelines. If necessary, a step-wise migration approach is described where compatibility is verified and consumers drive the transition to new versions.

1. 1
Auf dem Weg zur
Continuous API Delivery
API Evolution beherrschen
mit (Spring) Cloud Pipelines
Quelle: https://pixabay.com/de/rohr-leitung-pipeline-577581/
@maverick_1601@fpfleiderer
#WeAreHiring

2. 2
Quelle: http://www.google.de

3. 3
Consumer Driven Contract Testing
GET /customer/{id}
?fields=name
------------------------------------
{
“name”: “Max Meier”
}
{
“name”: “Max Meier”,
“age”: 34
}
GET /customer/{id}
?fields=name
Spring
Cloud
Contract
<<generated>>
ProviderTest
<<generated>>
WireMock Stubs
Consumer Test

4. 4
Quelle: https://philsturgeon.uk/api/2018/05/02/api-evolution-for-rest-http-apis/

5. 5
“Things have changed since WSDL back then …”
● Relaxed Schema
○ Resource based
○ Tolerant Reader
○ Relaxed type system based on JSON
○ No strict schema validation
● Maintenance
○ Evolution ideally consumer “driven”
○ Number of consumers outweighing providers
○ Effort for maintaining compatibility at provider
○ Avoid coupling, especially lock-step deployments, using step-wise migration
● Versioning
○ Last resort
API Evolution
{
“name”: “Max Meier”,
“age”: 34
}
GET /customer/{id}
?fields=name

6. 6
Consumer-Provider Relationships
GET /customer/{id}
?fields=name
{
“name”: “Max Meier”
}
{
“name”: “Max Meier”,
“firstName”: “Max”,
“lastName”: “Meier”
}
{
“firstName”: “Max”,
“lastName”: “Meier”
}
GET /customer/{id}
?fields=lastName,
firstName

7. 7
Managing API Compatibility
{
“name”: “Max Meier”
}
{
“name”: “Max Meier”,
“firstName”: “Max”,
“lastName”: “Meier”
}
{
“firstName”: “Max”,
“lastName”: “Meier”
}
GET
/customer/{id}
?fields=name
GET
/customer/{id}
?fields=name
GET
/customer/{id}
?fields=lastName,
firstName
GET
/customer/{id}
?fields=lastName,
firstName
{
“name”: “Max Meier”,
“firstName”: “Max”,
“lastName”: “Meier”
}
GET
/customer/{id}
?fields=lastName,
firstName
GET
/customer/{id}
?fields=name

8. 8
(Spring) Cloud Pipelines
Build Test Stage Production
● Maven/Gradle Build
● Publish to repository
● Unit Tests
● CDCT Tests
● API compatibility Tests
● Running Instance with
surrounding stubs
● Smoke Tests
● Running instances of
the whole system
● Manual deployment
step
● End-to-end Tests
● Tag current version
● Blue/Green Deployment
● Rollback possible
Quelle: https://github.com/spring-cloud/spring-cloud-pipelines

9. 9
Live Demo
Cloud Pipelines

10. 10
API Types
Order
Customer
Payment
Payment
Provider
Marketing
Public
Consumer
Public
Consumer
REST API with
“known” consumer
& provider
“Unknown”
REST API
consumers
Message-based
API with “known”
consumer &
provider
3rd-party REST
API with “limited”
provider control
Partner REST API

11. 11
1. Use Consumer Driven Contract Testing to decouple your development life-cycles
a. Ideal for known consumers/provider
b. Regularly check 3rd-party APIs using “proxy” contracts
c. Offer contracts to public consumers?
2. Preverse API compatibility by avoiding breaking changes
a. Consolidate consumer driven API changes
b. Verify backward compatibility using Cloud Pipelines
3. If necessary, use step-wise migration
a. Verify backward compatibility using Cloud Pipelines
b. Let consumers drive the breaking change
c. Keep track of consumers/providers still relying on older versions
Summary

12. 12
How are you dealing with API
evolution and compatibility?
#WeAreHiringQuelle: https://pixabay.com/de/feedback-checkliste-job-gut-3676922/
@maverick_1601@fpfleiderer
https://blog.digitalfrontiers.de
https://www.digitalfrontiers.de