Many of us pundits, analysts, and even practitioners in the API space believe in doing APIs the right way, or at least giving them the attention they deserve. This is commendable, but also the minority view of how you do APIs. Us technologists consciously and subconsciously ignore the business realities that exist on the ground for my API producers when we assume that everyone is interested in doing APIs well, and maximize the usage and adoption of their API. When you have looked at as many APIs as I have, and talked with as many API producers as I have, you realize that not everyone cares about their public API.
I emailed upwards of 1000 APIs as I did the work to populate the Postman Network after launching, asking if I could help folks generate OpenAPI and Postman Collections for their APIs, and publish them to workspaces. As I make my way through upwards of 250 API producers populating the APIs.json powered search index for APIs.io I am seeing many of the same realities I’ve seen at work before. Blogs that haven’t been updated for months or years. Inactive change-logs. Incomplete API documentation. When I was doing the outreach for Postman I actually received a few messages from folks regarding why they wouldn’t do the work—because more API consumers would mean more work for their already resource-strapped operations.
Everyone likes to tell me that I should rely on API producers to publish their own APIs.json. I agree, but I also know the reality of things on the ground in many of these API operations. They don’t have the time and resources to learn about APIs.json, let alone publish one, and spend the time to make sure it provides an accurate representation of their API operations. This is why I am open to doing it for them, to plant the seeds, but I am also looking for API service providers to make APIs.json a default feature, like Bump.sh has. I am looking for API service providers to do the heavy lifting for API producers when it comes to every stop along the API lifecycle, but specifically baking API discovery into every aspect of the solutions provided to API producers.
I am a big fan of API service providers offering useful modular API description driven services that API producers can put to work. I am also a big fan of open source API tooling providers having the resources they need to deliver useful modular API description driven solutions that API producers can put to work. I expect API service providers to do the work to make sure they are interoperable and utilize open source API specification, and not lock up API value generated. I’d like to believe that API producers in charge of public APIs have the resources they need, but I know the reality, and encourage them to leverage commercial and open-source API solutions. However, I am also a big fan of this stuff happening from the outside-in, and I think that API service providers and API tooling providers can overlay and augment public APIs with useful services, products, and tools that benefit API providers and the wider API community.
I think that those of us who care about doing APIs well and delusional believe that everyone should care need to be pragmatic and honest about the reality on the ground within public API programs. I think we need to focus and transfer this delusion into internally and externally applied services, tooling, and specifications that help augment the lack of resources and education on the ground. Things change and evolve within public API programs over time, and to help API producers better meet the needs of API consumers I think we need to all lend a hand in stitching together an API quilt of services, tooling, and specifications across the API lifecycle. As I’ve said before, I think it will take a village to properly raise and sustain an API, and we just can’t count on everyone caring about their public API as much as us believers, or even just the consumers who have baked an API into their operations.
