With the current state of coding harnesses that produce OpenAPI descriptions in incredible detail, the human aspect of the OpenAPI specification—viewing and editing— is no longer needed. The protocol should go all the way to tooling.

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.

IntroductionREST (OpenAPI) and gRPC are two of the most popular formats for APIs. REST is the style of choice of most public APIs, and gRPC is a popular alternative for internal APIs that need an efficient network. The OpenAPI Specification defines a standard to describe REST APIs and their capabilities. By default, gRPC uses Protocol Buffers, Google’s open-source mechanism for serializing structured data. The Protocol buffer schema is also an API specification.