Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Moving Beyond a Single API Developer Portal

DZone's Guide to

Moving Beyond a Single API Developer Portal

APIs and their ecosystems continue to grow and evolve at a rapid pace. Let's see how the role of API developer portals is changing and expanding.

· Integration Zone ·
Free Resource

The State of API Integration 2018: Get Cloud Elements’ report for the most comprehensive breakdown of the API integration industry’s past, present, and future.

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, managing, and evolving it as its own pipeline, or as part of individual projects and partner integrations? This is something that static CMSs have had 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 even outside industry influences.

Your API is not enough. Learn why (and how) leading SaaS providers are turning their products into platforms with API integration in the ebook, Build Platforms, Not Products from Cloud Elements.

Topics:
integration ,api portal ,continuous integration ,continuous deployment

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}