Testing OpenAPI definitions for better and consistent APIS Christos Gkoros API Architect - Platform engineering
All rights reserved by Postman Inc
Slide 2
Build APIs
All rights reserved by Postman Inc
Use APIs
Collaborate
Slide 3
Inside Postman 1.
API Design
2.
Scale
3.
Platform Engineering
4.
OpenAPI
5.
Spectral
6.
Test examples
Slide 4
The Postman API
Slide 5
Why integrate with the Postman API
●
Enhance Postman’s capabilities Providing users with the tools and resources to optimize.
●
Embed Postman within other workflows Like established processes enhances productivity and streamlines development.
Slide 6
As an API Architect I study
●
Why our users need the API
●
What functionalities they seek beyond the core product
●
How are they trying to do that
Slide 7
Common Use cases ●
Automation Scaffolding of Postman resources
●
Auditing Ensuring the Postman resources are as they should be
●
Tool integration Developer Portals CI/CD Test-planning, Test analysis, Test reporting …
Slide 8
My goals for the Postman API
1.
Simple and easy to use
2.
Effective at its job
3.
Increase its adoption and usage
Slide 9
API Design
Slide 10
Elements of a good design ●
Descriptive names Names that are descriptive names and aligned with the API’s goals
●
Rich Functionality User cans do easily what they need, like filtering with certain attributes.
●
Flexible formats The format is flexible and it adapts well on changes over time
●
Clear error messages Good experience especially during troubleshooting
Slide 11
API
API testing
API
API testing
API
Slide 12
Scale
Slide 13
Slide 14
Slide 15
API Gateway brings common
1.
Authentication
2.
Security
3.
Throttling
4.
Routing
5.
….
Slide 16
Slide 17
The Postman API needs to
1.
Have a common Look and Feel
2.
Be a unified product rather a mix of different endpoints
Slide 18
Recap - What do we need? ●
Good API Design
●
Consistency at scale
●
Autonomy
●
Fast delivery
Slide 19
Platform Engineering
Slide 20
Slide 21
Slide 22
Slide 23
Slide 24
Slide 25
Slide 26
Test examples
Slide 27
Contact information
Slide 28
Semantic Versioning
Slide 29
Resources are plural nouns
Slide 30
No resource nesting
Slide 31
Camel case parameters
Slide 32
Date Format
Slide 33
Collection must support pagination
Slide 34
Collections must support sorting
Slide 35
Parameters should have examples
Slide 36
No version in paths
Slide 37
Error format - Problem Details
Slide 38
Challenges ●
Testing the tests Since the tests are configuration files we need actually writing tests for them again
●
Some things are hard to test even with Spectral For example descriptive names, but AI could help with that
●
Re-evaluating tests As our API Design Guidelines involve we have to constantly adapt and update our tests
●
Design dept and breaking changes Some of the old endpoints are not compliant but we cannot change them as this wall cause errors in existing users.
Slide 39
Actions that you can do 1.
Figure out the API Design style you need
2.
Create Spectral rules to codify it
3.
Find a point in the critical path in the delivery life cycle that compliance testing can be performed
4.
Enforce the use of OpenAPI
5.
Implement your compliance testing
6.
Come meet me at the Postman booth for further discussion.
Thank you