Ready to start?
There’s an API explosion going on.
The move to cloud-native development, breaking up of silos into microservices, adoption of API-first and API-enabled approaches, all led to great innovation. These changes also brought a lot of complexity and made the developer experience more difficult and fragmented. Managers and leaders also have related questions around API governance, quality and control.
APIs are created often without a centralized place for management and governance. This explosion of APIs led to a chaotic landscape where the following becomes a challenge:
- Discoverability: Letting developers find the right API for a specific task or project.
- Documentation: Helping developers access up-to-date API documentation.
- Governance: Providing the assurance to engineering leadership that APIs are compliant, consistent, of good quality and secure. .
- Optimization: Ensuring the engineering organization as a whole avoids effort duplication.
The latter point is important. With API explosion and no way to manage them, valuable engineering resources are hidden, underutilized, or even duplicated. This not only harms productivity and slows down development velocity but also creates security and governance risks.
Without a central, globally searchable source of truth for API existence or quality, the easiest path is to create an overlapping API or (less commonly) completely duplicate an API, thus hindering current and planned modernization.
To solve this issue, organizations are turning to two essential tools: API catalogs and internal developer portals with an API catalog. But what exactly are they, and how are they different? In this blog post, we'll discuss API catalogs and API portals, exploring how they can help you regain control of your API ecosystem.
Internal vs. External API Catalogs
It's important to note that API catalogs can serve two different purposes for two different audiences.
- Internal API Catalogs, which are designed for use within an organization, primarily serving developers or other internal stakeholders. They focus on promoting code reuse, and efficient development by providing a centralized repository of internal APIs with their documentation.
- External API Catalogs: These serve customers, partners, and others, interested in integrating with a company's products or services.
In this article, we will focus on internal API catalogs (also referred to here as API catalogs).
What are API catalogs?
An API catalog is a central repository for all APIs within an organization, where developers and other stakeholders such as product managers can easily discover, access, and understand all APIs available without the need to reach out to contacts or search through various systems.
Traditionally, API catalogs include the following information:
- Functionality: a description of what the API does.
- Code snippets: request and response examples
- Parameters: the input values required to trigger specific functionalities.
- Error codes: a list of the potential errors that the API might return
- Authentication mechanisms: the methods used by the API to check the identity of the applications trying to access it.
Such API catalogs can appear as a feature in tools like postman, or Smartbear which allows developers to test, document, and share APIs, by providing a user-friendly interface for making requests, viewing responses, and debugging issues.
However, advanced API catalogs go beyond the basics and offer a more comprehensive experience. They’ll usually include additional information that is valuable for both API owners and consumers:
- Usage statistics that includes information such as when the API was last called, which services are using it most frequently, and the average response time.
- Developer feedback, allowing developers to rate and review APIs.
- Health score, that indicates the overall performance and reliability of an API
- Additional metadata: You can add to the catalog additional information such as API ownership, contact details for support, and links to other relevant resources.
Why should you use an API catalog?
By providing this additional information, the API catalog allows developers looking to use an API to:
- Make informed decisions: Select the right APIs for their projects based on usage data and feedback.
- Collaborate effectively: Share feedback and ratings to help improve the API ecosystem.
For API owners, the benefits are:
- Understand API usage: Get insights into how APIs are being used, shedding light into popular endpoints, usage patterns, and potential bottlenecks.
- Troubleshoot issues: Identify potential problems with an API based on its health score and usage patterns.
- Improve communication: Address concerns, announce updates, and gather input.
API catalog tools can be found as a feature in popular API management platforms, such as Postman and Apigee. Additionally, you can build an open source API catalog with tyk.io and other similar tools.
What is an API catalog in an internal developer portal?
Internal developer portals were built to solve similar problems to those addressed by API catalogs. Instead of solving issues of API explosion, they address the issues of microservices explosion. However, their inherent capabilities allow the inclusion of API data into the software catalog at the heart of the portal, supporting an API catalog use case for the portal.
Internal developers were built to solve a larger problem of developer experience and developer self-service and are made to provide strong context and data to developers, abstracted for them, alongside developer self service actions. As such, they offer more than traditional API catalogs by showing
- APIs in context
- Enriched metadata or structured performance feedback on the quality of the API
They also deliver improved developer experiences across self-service, workflow automations and the ability to better control quality and compliance of APIs, using scorecards.
Self-service actions
A key differentiator of API developer portals is their self-service capabilities. They allow developers to:
- Easily scaffold APIs that are compliant and secure by default: By creating templates and exposing them to developers, you can ensure that new APIs comply with organizational standards and promote consistency and reliability.
- Streamline API Lifecycle Management: Create self-service actions to register, publish, certify, deploy, and deprecate your APIs, all from one unified interface.
Scorecards
Scorecards help ensure API quality and compliance. They evaluate the API against predefined rules and provide important insights to API owners, consumers as well as for engineering management. Scorecards can be used for
- Security: Scorecards can check for example HTTPS enforcement, authentication mechanisms, and other security best practices.
- Reliability: Monitor API response times, error rates, and other performance indicators.
- Production Readiness: Assess if an API has an owner, proper documentation, configured health checks, and other essential elements.
Initiatives
API developer portals enable managers to track and manage initiatives aimed at improving API governance. Using initiatives, you can easily:
- Identify APIs that lack proper documentation or don’t meet mandatory requirements.
- Monitor how many APIs still need attention.
Dashboards
Dashboards provide customized information to different stakeholders, easing API governance and troubleshooting. Using a developer portal you can create the following dashboards
- A manager dashboard: Focus on business-critical APIs, displaying the most used APIs, their response times, distribution of response codes, and progress on key initiatives.
- An API owner dashboard: Offer insights into individual API performance, including monitoring data, recent feedback, health scores, and top consumers.
Main differences between API catalogs and API developer portals
API catalogs act as a central repository for APIs. They offer a searchable index as well as detailed documentation for each API. This documentation typically covers functionalities, endpoints, parameters, request and response formats, error codes, and usage examples. Essentially, API catalogs help developers discover relevant APIs and understand how to use them best.
API developer portals, however, go beyond just discovery and documentation. They provide a platform that lets developers manage the entire API lifecycle. This includes tasks like creating new APIs using templates, registering API, publishing them, and eventually deprecating them when they are no longer needed. Additionally, developer portals often integrate with API management tools, enabling functionalities like API security enforcement, rate limiting, and analytics.
In short, while API catalogs are often a core component of a developer portal, it represents just one piece of the puzzle.
Beyond APIs - all developer experiences in one place
While APIs are critical assets in every engineering organization, they are not the only software components that developers need to manage throughout the SDLC. Developers also work with services, packages, deployments, and more.
A developer portal recognizes this interconnectedness and provides a unified platform where developers can manage all these components seamlessly.
By integrating API management into the broader development workflow, organizations can achieve:
- A streamlined end to end development experience: Developers can manage all aspects of their projects—from code repositories and build pipelines to API documentation and deployment configurations—within a single centralized place.This eliminates the need to switch between multiple siloed tools and reduces cognitive load.
- Better Collaboration: Using a portal, developers can share information about APIs, services, and deployments and more, easing communication and knowledge sharing.
- Improved Visibility: Teams can track the progress of projects, identify dependencies, and assess the impact of changes across different components.
By including more than just API management, developer portals become the place for everything development, allowing teams to work more effectively, deliver higher quality software, and accelerate innovation.
Conclusion
Using an internal developer portal, platform engineers can create a single, searchable API marketplace that will reduce waste and cognitive load and offer developers
- The confidence in the quality of the APIs consumed
- APIs that are held to a high standard
- The ability to scaffold new APIs
- In context data about APIs, which services consume them etc
Check out Port's pre-populated demo and see what it's all about.
No email required
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Check out Port's pre-populated demo and see what it's all about.
(no email required)
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Book a demo right now to check out Port's developer portal yourself
Apply to join the Beta for Port's new Backstage plugin
It's a Trap - Jenkins as Self service UI
Further reading:
Example JSON block
Order Domain
Cart System
Products System
Cart Resource
Cart API
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Component Blueprint
Resource Blueprint
API Blueprint
Domain Blueprint
System Blueprint
Microservices SDLC
Scaffold a new microservice
Deploy (canary or blue-green)
Feature flagging
Revert
Lock deployments
Add Secret
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Development environments
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Cloud resources
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
SRE actions
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Data Engineering
Add / Remove / Update Column to table
Run Airflow DAG
Duplicate table
Backoffice
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
Train model
Pre-process dataset
Deploy
A/B testing traffic route
Revert
Spin up remote Jupyter notebook
Engineering tools
Observability
Tasks management
CI/CD
On-Call management
Troubleshooting tools
DevSecOps
Runbooks
Infrastructure
Cloud Resources
K8S
Containers & Serverless
IaC
Databases
Environments
Regions
Software and more
Microservices
Docker Images
Docs
APIs
3rd parties
Runbooks
Cron jobs