Being The Source Of API Truth At Your Organization
When doing web services and API inventory at enterprise organizations I always come across one or two individuals or groups who are the keepers of the APIs, schema, and related knowledge and truth within the organization. It is the new version of the database keepers within large organizations, but instead of it just being just about data, it is about access to all types of resources, including data, content, algorithms, network, and other infrastructure elements. Being the API knowledgebase, directory, and source of truth within an organization takes a lot of work, but it is something that will pay off down the road when it comes to actually getting things done within an organization.
I have had a database of APIs since 2011, but it has mostly been for my discovery only. Historically I have published some of these to GitHub, and I’m working on different ways of making them available via search, but now that I’m working at Postman, I am considering making them available in different ways via Postman workspaces, and collections. Ideally, API providers would publish their own API definitions to Postman to the Postman API network, so I could just rely on API provider verified collections, but until that day I'll keep working on crafting them myself. Even once I have a complete API collection, I still find that my way of organizing a collection, and pre-populating Postman environment with certain variables often goes far beyond what most API providers will offer up in their own collections.
I’m looking for some of my hand-crafted Postman Collections and Templates to become the source of truth when it comes to some of the APIs I'm telling stories about. I don’t just want to be the person people come to for interesting APIs with complete API definitions, I want them to come to me because I am pre-populating them with meaningful values, naming them using more meaningful labels, and making them available via accessible workspaces. Helping uncover some of the more interesting API use cases out there, while also making APIs more accessible to developers, and hopefully even non-technical users. I am all about being the source of truth for important API definitions, helping people not just find the APIs that exist, but also be able to quickly put them to work.
Postman provides a pretty simple and free way to begin organizing API definitions in a very useable way. It is something that you can slowly gather and organize over time, and begin making available to different team members via carefully crafting workspaces. It is something you can start out doing for free, and then as it grows in adoption amongst team members you can sell your boss on going pro or enterprise, depending on the size of your team(s). I’m going to work to better organize my API catalog using Postman collections, teams, environments, and templates, then tell the story along the way. I have a couple thousand APIs I want to organize and make accessible. I’m guessing I am going to learn a thing or two along the way, making for some pretty good stories to tell, and eventually some guides to help other people become the source of truth for APIs within their organization.