Skip to content

Latest commit

 

History

History
32 lines (26 loc) · 5.56 KB

portals.md

File metadata and controls

32 lines (26 loc) · 5.56 KB

Portals

Internal, partner, and public API portals are now common across the enterprise landscape, having been introduced as part of an earlier SOA investment, or more recently, as part of an API management investment. Portals play a critical role in onboarding and engaging with users. But like other parts of the API life cycle, they are evolving, and often struggling to keep up with the changes happening across API operations.

Moving to Experience

Internal and external developer portals play a foundational role across API operations and full lifecycle API management as defined my that last generation of API service providers. Portals provide a central place internally or externally for API producers and consumers to discover APIs, access documentation, code libraries, and other resources. From our vantage point, we see the pace of operations and digital transformation outpacing traditional approaches to API portals, with our most progressive customers publishing a variety of API products to portals, but also exposing API workspaces publicly and with partners. These customers are then weaving reference, onboarding, workflow, and other types of API collections into portal documentation using Run in Postman buttons, then going even further to meet developers where they are—embedding buttons to executable and documented collections within workspaces inside blog posts, white papers, workshops, webinars, and other elements of a modern developer experience. The API portal isn’t going anywhere, but a more networked approaching using private, partner, and public workspaces that are seamlessly presented as part of your overall developer experience is the approach we are seeing keep pace with the digital transformation occurring across enterprise organizations in almost every industry today.

  • Workspaces - Work on a new API always begins in a dedicated workspace. Make sure there is a single place where teams can find artifacts and the work that exists behind each API.
  • Contract - Every API has a machine-readable contract describing the surface area of the API, providing an understanding between API producer and consumer to guide operation.
  • Mocks - The contract for an API is perpetually used to generate mock servers, helping make the API design as realistic as possible by matching specific use cases with examples.
  • Document - Documenting means generating human-readable documentation from an APIs contract, ensuring that it is accurate and uptodate for each API as it is being designed.
  • Feedback - Provide a feedback mechanism for all stakeholders to use with the current design of an API, helping guide teams to add new features, capabilities, and experiences.
  • Iterate - Aggregate feedback from consumers and other stakeholders.Identify sensible changes to the API, then iterate on the contract, updating mocks and documentation.
  • Tests - Once the contract for an API has been established, and there will be no more iterations to this version, you can produce contract tests to validate that an API delivers upon the original intent when in production.
  • Develop - Hand off the API contract, providing teams what they need to bring an API to life in development. Move to staging and tests before it goes into production.

Filler

This is just filler content

  • Internal - Internal API portals exist as part of legacy investment in API management solutions. They often needmore work and engagement to ensure they are keeping pace with the rate of change.

  • External - Publicly available API portals are becoming a common fixture of enterprise public websites. They provide a public doorway to digital resources and capabilities available for use in business operations.

  • Network - Networks provide an opportunity to connect your private, partner, and public APIs to a larger network of developers. That will help automate discovery not only of APIs, but of the mock servers, tests, and other aspects of API operations.

  • Documentation - Human-readable API documentation has become a staple of portals, providing HTML views of what is possible with APIs. Documentation describes how to use them, providing examples that demonstrate potential and speak to developers.

  • Onboarding - Portals are the doorway to API consumption. They show consumers what is possible and how to get started putting APIs to work as part of applications and integrations.

  • Community - One way to breathe more life into your API ecosystem is to build, attract, and cultivate community within your own API portal. You can also link g to other networks to engage with developers in the communities they frequent.

  • Support - Providing support to API consumers offers a rich opportunity for building trust and ensuring they successfully put your APIs to use.

  • Discovery - A well-maintained portal provides a rich opportunity for helping producers and consumers discover new APIs when they want to develop new APIs of their own, plan new applications and integrations, or put resources to work.

  • Experience - Portals aren’t just about providing documentation and support. They are about delivering meaningful and enjoyable experiences for consumers and making digital resources and capabilities more accessible for developers. null Portals are an established aspect of API operations, and are making incremental shifts to keep up with the pace of change across operations. These shifts are helping to deliver the experiences today’s consumers expect,, reducing their time to first call and making sure they always have access to the latest and greatest experiences.