Testing OpenAPI definitions for better and consistent APIs

A presentation at WeTest Athens in June 2024 in Athens, Greece by Christos Gkoros

Slide 1

Slide 1

Testing OpenAPI definitions for better and consistent APIS Christos Gkoros API Architect - Platform engineering All rights reserved by Postman Inc

Slide 2

Slide 2

Build APIs All rights reserved by Postman Inc Use APIs Collaborate

Slide 3

Slide 3

Inside Postman 1. API Design 2. Scale 3. Platform Engineering 4. OpenAPI 5. Spectral 6. Test examples

Slide 4

Slide 4

The Postman API

Slide 5

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

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

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

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

Slide 9

API Design

Slide 10

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

Slide 11

API API testing API API testing API

Slide 12

Slide 12

Scale

Slide 13

Slide 13

Slide 14

Slide 14

Slide 15

Slide 15

API Gateway brings common 1. Authentication 2. Security 3. Throttling 4. Routing 5. ….

Slide 16

Slide 16

Slide 17

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

Slide 18

Recap - What do we need? ● Good API Design ● Consistency at scale ● Autonomy ● Fast delivery

Slide 19

Slide 19

Platform Engineering

Slide 20

Slide 20

Slide 21

Slide 21

Slide 22

Slide 22

Slide 23

Slide 23

Slide 24

Slide 24

Slide 25

Slide 25

Slide 26

Slide 26

Test examples

Slide 27

Slide 27

Contact information

Slide 28

Slide 28

Semantic Versioning

Slide 29

Slide 29

Resources are plural nouns

Slide 30

Slide 30

No resource nesting

Slide 31

Slide 31

Camel case parameters

Slide 32

Slide 32

Date Format

Slide 33

Slide 33

Collection must support pagination

Slide 34

Slide 34

Collections must support sorting

Slide 35

Slide 35

Parameters should have examples

Slide 36

Slide 36

No version in paths

Slide 37

Slide 37

Error format - Problem Details

Slide 38

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

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