I’ve been working a couple organizations who are struggling with providing information within their API developer portal intended for API publishers, pushing their API portal beyond just being for their API consumers. Some of the folks I’ve been working with haven’t thought about their API developer portals being for both API publishers and consumers, and asked me to weigh in on the pros and cons of doing this. Helping them understand how they can continue their journey towards not just being an API platform, but also an API marketplace.
Some of the conversations we were having about providing API lifecycle materials to API developers, helping them deliver APIs consistently across all stops along lifecycle, focused on creating a separate portal for API publishers, decoupling them from where the APIs would be discovered and consumed. After some discussion, and consideration, it feels like it would be an unnecessary disconnect, to have API publishers going to a different location than where their APIs would end up being discovered, and integrated with. That having them actively involved in the publishing, presentation, and even support of, and engagement with consumers would benefit everyone involved.
Think of it being like Rapid API, but a large company, organization, institution, or government agency. You can find APIs, and integrate with existing APIs, or you can also become an API publisher, and be someone who helps publish and manage APIs as well. You will have one account, but you can find documentation, usage information and other resources for the APIs you consume, but then you will also access information, and usage data on the APIs you’ve published. Pushing API developers within an organization to actively think about both sides of the API coin, and learn how to be both provider and consumer. Helping add to the catalog of APIs, but also helping evolve and grow the army of API people across an organization.
We still have a lot of work ahead of us when it comes to fleshing out what type of information we should provide to API publishers, and how to cleanly separate the two worlds, but I feel the realization that a portal can be both for API publishers and consumers was an important one for these groups. I feel like it represents a milestone in the maturity and growth of their API programs, where the API developer portal has grown into something that everyone should be tuning into, and participating in. It isn’t just something that a single team, or handful of individuals managed, and it is has become something that is becoming a group effort. Sharing the load of operating the API portal, and keeping things up to date and active, further contributing to the potential success of the platform, shielding it from becoming yet another web service or API catalog that gets forgotten about on the network.
