apidays LIVE Paris 2021 - APIs and the Future of Software December 7, 8 & 9, 2021 Inside API delivery Pipeline, the checklist! François Lasne, Director Open API & Open Banking at Finastra

1. Inside the Finastra API delivery pipeline,
the checklist !

2. Francois LASNE
Director Open API
FusionFabric.cloud
Finastra
Member of
#PSD2
Member of
80+ companies
workshop owner about API governance
#OpenBanking
https://www.linkedin.com/in/francoislasne/

3. From a specification to production
Open API Specification
Is not only a text file
It’s a ‘serious’ contract
With great power comes great responsibility

4. No automation can replace a review
Share with domain expert
Share API evangelist
Review at early stage
API First, not Code first
Accept compromise
Get global agreement
Still tooling helps to catch a lot
Git, Jira, Azure pipeline, linter …

5. Specification as Code
following Git workflow model (Azure Devops)
Feature branch Initial commit
Develop branch
Master branch
Pull Request review
merge
Deploy on preprod
Promotion to
prod
Deploy API GW
Dev env.
Automatic check
700+ actives users , a centralized validation team responsible of
* API quality
* Deployment CICD

6. Inside the
API delivery pipeline,
How we ensure
Good quality

7. Do you have a standard? Enforce / Encourage it , by using validation tool
150 rules
• Style (invalid char, camelCase)
• Information (description , title )
• Field specification
– Format, maxSize, date
• Operation
– If-match (PUT) / Etag GT
– GET no body
– Error code 404 if /{id}
• Security compliance (Oauth2, scope )
• Bad patterns , ID , details, info
date with no date, 1 char value
• Vetted list of headers
API Linter save time

8. Be an example … with your example
Example Validation
Example
Check field names compliant
Check fields types , and constrains
Check example enum values
…
As well as default values
+ Strict compliance with Open API spec
{
"country": {
"description": "ISO 3166 ALPHA2 country code.",
"type": "string",
"pattern": "[A-Z]{2}",
"example": "France"
}
}

9. Breaking change detector
Because a breaking change can be introduced without being notice
• Adding required parameters
• Changing field name , or field type
• Detect that version has not change
47 rules
enforced for GA API, warning for Beta
https://github.com/Azure/openapi-diff
Semantic versioning v1.2.3
Path versioning for major version

10. API specification is a public artefact, but often written by developers
Check title and description
But what about fieldName ?
Cspell Code checker, handle camelCase , trainCase and more
Allow customized Dictionnary
Run in CICD as well as in Visual Studio Code
When doing API first ,
Very powerful to detect Typos in field name that can have bad consequences
##[warning]swift-standing-order-api-v1Swagger.json:7:46 - Unknown word (Instrction)
Suggestions: [instruction, instructions, insertion, inspection, infarction]

11. Data classification process
API specification
Rules set
Defined Data Type
Field Name + and fields patterns
Global
end point level
Field level
Used as well to handle a global dictionary , in combination with Cspell check
used to handle vocabulary consistency across the company

12. Test your test
Providing Postman collection is great
Testing them is better
@each deployment
On a regular basis , the postman collection offered it CICD tested (B2B / B2C flow)

13. Are you lying to me ?
Payload checker
Payload checker
Done as part of Postman testing, @ each deployment
Done asynchronously on a continuous way for the core,
Alerts “core” team
Not targeting client side for now (security) but server side (quality)

14. My errors are good !
Error injection
Inject GET /bob => validate 404 error
Introduce Token erasure at GW level => validate 401
Introduce dummy if-match => validate concurrency
Introduce dummy payload => validate 400

15. Let s add one more rules …
Test results
Error
warning
classification
200 + Specs
1.3 K endpoints
40 git repos
Massive non regression tooling and statistics

16. Did you enjoy the ride

17. I have a challenges / I have a dream
challenges Dream
Bespoke Code for Iinter
Dual support OAS2 , OAS 3 is a pain,
json schema as well !
API review tooling
Ensuring Consistency at scale
Move to opensource and sharable rules
(Spotlight Spectral , Zalando Zally)
Larger support of OAS 3
Better tooling for re use
Stronger standardization
Better tooling for API review

18. Annex

19. High level view to ensure good quality
• Structure validation
• Swagger Linter
• Data classification
• Breaking Change detection
• Example validation
• Deployment to API Gateway, code artifact repository
• Affect a backend , or generate a Mock server
• Play postman Collection,
• Payload compliance checking
• Play BDD testing / performance testing
• Inject ‘common’ testing pattern (404, 4XX, etc)
@ Each Commit in a Pull Request
@ Each deployment
(test, uat, prod)

20. What s next

21. Let’s start with a use case
Looking for an Identity validation provider, putting myself in the shoes of an API consumer
No Test no way !
There are plenty of providers , all with API
Your Documentation need to be perfect, Self explainable.
I do not understand , Next ….
Slow motion model, contact sales, to get to dev portal … bye bye
It must be Self Service
Your testing capability, Postman collections, sample
and it must work !
But this is weird !
Your API model should follow industry standard (ISO & REST
concept )

22. Breaking change
Develop branch
Feature branch
Still compatible ?
Do I break Fintech integration
https://github.com/Azure/openapi-diff/tree/master/docs
Allowed for Beta not for GA
• Add a path
• Add a non mandatory field
• Change in field name
• Change in api path
• Change of type
Apply semantic versioning and update the version on master