https://noti.st/christosgkoros/62Hs9L/testing-openapi-definitions-for-better-and-consistent-apis Here, I present how we test APIs described with the OpenAPI standard internally at Postman. We will cover the objectives of testing, which include ensuring correct structure, completeness, consistency, uniformity, style, and documentation. Additionally, we will explore the tool used for testing, Spectral, and where testing fits in our software delivery lifecycle. Furthermore, we will discuss the challenges we faced, such as testing the tests, scaling the number of tests, and scaling the number of engineering teams involved, and how we overcame them.

Lay out the Context An API does not live in isolation. It is part of business, involves people, and may sit next to other APIs. All these are necessary to scope and design the API. Instead of that, you could create many integration pipes. It would be difficult to understand them all in a few years. Input: Interviews, relevant api designs, business & architecture diagrams, engineering docs. Identify the nonfunctional requirements Review the security model & performance expectations.

For the last year, I have been working on what “better API design” means. How can we better design the public and our internal APIs? The term that comes to my mind to define this is maturity, thus API design maturity. What is API design maturity, then? When I searched on Google, most of the results were about the Richardson Maturity Model. Some results may refer to API-First and how an organization generally treats APIs.