I am always wondering how much of the API sector is a construct of API providers, or something that was introduce by API service providers. Ok, I guess there is probably a third category of how much is manifested by analysts, storytellers, and bullshitters like me. One of the building blocks I have been pondering on lately is the concept of the developer or API portal. While it is something you can find organically growing in the wild, I’d say that mostly it is something you find being a construct or deliverable of the latest couple of waves of API management providers. Leaving me wondering what came first, the API management portal, or the API portal? Also, pushing me to ask other questions like whether or not we need the API portal at all?
I am a big fan of having a single developer.example.com portal to visit for every domain. I don’t think we should be getting rid of centralized API portals and catalogs for companies, but I am questioning (as I always do) the belief systems we have in place, wondering if we’ve become trapped by our own narratives along the way. I feel like many APIs I use do not need wider availability via a central API catalog and it helps to just be able to provide URLs to the API documentation, which should give me everything I need to on-board and being putting an API to work. Not all APIs are ready for prime time, and just needs sharing amongst a tighter group of shareholders, and depending on the life cycle and evolution of the API, it may or may not need publishing to central catalog.
If an API possesses a dedicate URL to a landing page with the essential building blocks like sign-up, documentation, code snippets, support, TOS, and other essential building blocks, does it need to be published to a single, comprehensive API portal? I am noticing that the operation of centralized API portals are becoming a point of friction within large enterprise organizations, where there isn’t always agreement in how and who should be operating the portal, and what the requirements and governance involved in publishing APIs to a collective location. Pushing some API providers to start their own catalogs, or just publishing APIs via their own GitHub hosted, or other landing pages, where they publish docs and other supporting elements. In my opinion, a central API catalog is a good thing, but if it starts getting in the way of API developers making their API resources available, and injecting friction into the process, then we should be asking more questions about whether or not we are making the right decision here.
While developer portals are largely a positive building block in the API ecosystem, I feel like the tractor beam of API management vendors has dominated the discussion around what should be the presence of each API we publish. I’m not saying this needs to go away, and I’d love to see more API management providers begin to innovate in this area, and begin thinking out of the box when it comes to the discoverability of our APIs, and how we empower API developers to share their resources. I think that public and private API portals should be default for all organizations. However, I also think there should be other frictionless ways of publishing public and private APIs, while still ensuring they have all the necessary building blocks for success, and ensure the APIs are discoverable by any stakeholder involved. At the very least, I think we should always be questioning the constructs we put in place, regularly asking how we got here, and if everything we are doing makes sense—keeping things fresh and always changing when it makes sense.
