Postman, Bruno, and Insomnia collections are commonly used for both formal and ad hoc support of API consumers. In contrast, OpenAPI is often regarded as the source of truth for an API, serving as the foundation for developer-facing API documentation. OpenAPI tends to be more foundational, while collections are typically more ephemeral and supplementary. However, with the release of Bump’s OpenAPI-powered API Explorer, we’re seeing a shift in how OpenAPI and collections can be leveraged. They are increasingly being used not only for technical purposes but also for sharing, support, sales, and other business-related activities.
- Single Use - Defining more modular and single-use API requests that convey a single concept to consumers.
- Use Case - Focusing on a specific use case of a business sector and defining an API in terms of a capability.
- Support - Providing support to API consumers, helping with a specific API, and getting on the same page.
- Troubleshooting - Capturing a single problem occurring with an API and then sharing that back with teams.
- Difference - Establish a diff that can be used to understand the state of the live API and a single application.
- Changes - Helping track on and evaluate changes that are occurring and surfacing events to API stakeholders.
An OpenAPI or Collection can represent a wide range of APIs, from a comprehensive API set to a granular operation or specific business use case. While there has always been some overlap in how OpenAPI and Collections are used in API operations, the gap between their applications is narrowing. OpenAPI provides detailed information about request and response payloads, whereas Collections include built-in scripts and automation. While some clear distinctions will always remain, the ways OpenAPI and Collections are being applied across the API lifecycle are increasingly converging.
