I am working with a number of different groups who are using developer portals in some very different ways once they have moved beyond the concept that API developer portals are just for use in the public domain. With the introduction of the static site shift in the CMS landscape, and the introduction of Jekyll and Github Pages as part of the Github project workflow, the concept of the API developer portal is beginning to mean a lot of different things, depending on what the project objective is.
An API portal is becoming something that can reflect a specific project, or group, and isn’t something that always has a public URL. Here are just a few of the ways in which I’m seeing portals being wielded as part of API operations.
- Individual Portals - Considering how developers and business users can be leverage portals to push forward conversations around the APIs they own and are moving forward.
- Team Portals - Thinking about how different groups and teams can have their own portals which aggregate APIs and other portals from across their project.
- Partner Portals - Leveraging a single, or even partner specific portals that are public or private for engaging in API projects with trusted partners.
- Public Portal - Begin the process of establishing a single Mutual of Omaha developer portal to provide a single point of entry for all public API efforts across the organization.
- Pipeline Integration - How can BitBucket be leverage for deploying of individual, team, partner, and even the public portal, making portals another aspect of the continuous deployment pipeline.
One of the most interesting shifts that I am seeing is the deployment of portals as part of continuous deployment and integration pipelines. Since you can host a portal on Github, why not be deploying it, managing and evolving it as its own pipeline, or as part of individual projects, and partner integrations. This is something that static CMSs have have a profound effect on, as well as the integration of YAML, JSON, and CSV static data formats, which can be used to deliver data, content, and configurations that can be used throughout project pipelines.
Like every other stop along the API life cycle, API portals are quickly becoming more modular, and often times more ephemeral, shifting from the days where we just had one single API portal. We are beginning to move beyond just the concept of a single portal, and seeing a mix of API centric destinations that are public or private, and reflect the changing objectives of different teams, partners, and event outside industry influences.
