This is an automated email from the ASF dual-hosted git repository.
Yilialinn pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new 1658081c72d docs: add API management and governance learning center
guides (#2105)
1658081c72d is described below
commit 1658081c72d317da9208f26d6ca8b1c795a5e41f
Author: Yilia Lin <[email protected]>
AuthorDate: Thu Aug 20 20:55:49 2026 +0800
docs: add API management and governance learning center guides (#2105)
---
website/learning-center/api-gateway-security.md | 2 +-
.../api-gateway-vs-api-management.md | 166 +++++++++++++++++
website/learning-center/api-governance.md | 199 +++++++++++++++++++++
website/learning-center/apisix-vs-apigee.md | 2 +-
website/learning-center/what-is-an-api-gateway.md | 2 +-
website/src/pages/comparisons.tsx | 6 +
website/static/llms.txt | 2 +
7 files changed, 376 insertions(+), 3 deletions(-)
diff --git a/website/learning-center/api-gateway-security.md
b/website/learning-center/api-gateway-security.md
index 088042ce9e3..fa6711065da 100644
--- a/website/learning-center/api-gateway-security.md
+++ b/website/learning-center/api-gateway-security.md
@@ -120,7 +120,7 @@ APISIX also supports JWT authentication, key
authentication, OpenID Connect, rat
### What is the difference between API gateway security and API security?
-API security is the broad discipline of protecting APIs across their entire
lifecycle, including design, development, testing, and runtime. API gateway
security specifically refers to the security controls enforced at the gateway
layer during runtime, such as authentication, rate limiting, and input
validation. The gateway is one component of a comprehensive API security
strategy, not a replacement for secure coding practices and security testing.
+API security is the broad discipline of protecting APIs across their entire
lifecycle, including design, development, testing, and runtime. API gateway
security specifically refers to the security controls enforced at the gateway
layer during runtime, such as authentication, rate limiting, and input
validation. The gateway is one component of a comprehensive API security
strategy, not a replacement for secure coding practices and security testing.
An [API governance framework](/learning- [...]
### Should I terminate TLS at the API gateway or at the backend service?
diff --git a/website/learning-center/api-gateway-vs-api-management.md
b/website/learning-center/api-gateway-vs-api-management.md
new file mode 100644
index 00000000000..59352ae7ded
--- /dev/null
+++ b/website/learning-center/api-gateway-vs-api-management.md
@@ -0,0 +1,166 @@
+---
+title: "API Gateway vs API Management: Key Differences"
+description: "Compare API gateways and API management across runtime traffic
control, API lifecycle, governance, developer experience, and when teams need
both."
+slug: api-gateway-vs-api-management
+date: 2026-08-20
+tags: [api-gateway, api-management, comparison]
+hide_table_of_contents: false
+---
+
+An API gateway and API management solve related but different problems. An API
gateway sits in the request path and applies runtime policies such as routing,
authentication, rate limiting, and observability. API management covers the
wider API lifecycle, which can include design standards, publishing, discovery,
developer onboarding, governance, analytics, and retirement. A gateway can be a
component of an API management program, but it is not the entire program.
+
+The distinction matters when teams evaluate products or design an API
platform. A team may need only a reliable runtime gateway, or it may need a
broader operating model that coordinates API work across many teams and
consumers.
+
+## What Is an API Gateway?
+
+An API gateway is infrastructure that receives API requests, evaluates
configured policies, and forwards accepted requests to backend services. It
operates at runtime, so its decisions affect live traffic.
+
+Typical responsibilities include:
+
+- Matching requests to routes and upstream services
+- Authenticating callers and applying common access policies
+- Enforcing rate limits and quotas
+- Rewriting headers, paths, or payloads when configured
+- Terminating TLS and managing gateway trust boundaries
+- Balancing traffic and supporting canary delivery
+- Exporting metrics, logs, and trace data for requests that pass through it
+
+The gateway is therefore a policy enforcement point. It does not automatically
define who owns an API, approve a breaking schema change, maintain an API
catalog, or manage the full consumer relationship.
+
+## What Is API Management?
+
+API management is the set of practices and supporting tools used to operate
APIs throughout their lifecycle. Depending on the organization and platform, it
can include:
+
+- API design standards and contract review
+- An inventory or catalog of APIs and owners
+- Documentation and publishing workflows
+- Developer onboarding and credential issuance
+- Runtime gateway policies
+- Usage analytics and API product reporting
+- Versioning, deprecation, and retirement processes
+- [API governance](/learning-center/api-governance/) and exception management
+- Subscription, entitlement, or monetization workflows
+
+Not every API management product includes every capability, and some
organizations assemble these functions from multiple tools. The defining
difference is scope: API management coordinates the API lifecycle, while the
gateway controls traffic during API consumption.
+
+## API Gateway vs API Management at a Glance
+
+| Dimension | API Gateway | API Management |
+|---|---|---|
+| Primary scope | Runtime API traffic | API lifecycle and operating model |
+| Position | In the request and response path | Across design, publication,
runtime, and retirement |
+| Main users | Platform engineers, SREs, application teams | API platform
teams, API owners, developers, security, and product teams |
+| Core concerns | Routing, authentication, rate limiting, transformation,
traffic telemetry | Standards, discovery, onboarding, governance, analytics,
lifecycle, and runtime control |
+| Required for every request | Yes, for APIs routed through it | No; many
management activities happen outside the request path |
+| API catalog | Usually outside gateway scope | Common capability or connected
system |
+| Developer portal | Usually outside gateway scope | Common for partner or
public API programs |
+| Runtime policy enforcement | Core responsibility | Usually provided by an
integrated or connected gateway |
+| Design-time checks | Usually handled by CI or design tools | Often part of
the management process |
+| Business analytics and monetization | Gateway can emit usage data | May add
products, plans, subscriptions, and billing integration |
+
+These categories overlap because many API management platforms include a
gateway. Conversely, an API gateway can integrate with design, catalog, portal,
analytics, and identity tools without being sold as a single API management
suite.
+
+## The Architectural Difference
+
+The gateway belongs on the runtime data path:
+
+```text
+API client -> API gateway -> backend service
+ |
+ +-> runtime policies and telemetry
+```
+
+API management spans systems and workflows around that path:
+
+```text
+Design and review -> publish and discover -> gateway runtime -> observe ->
version or retire
+ | | | |
+ API contracts catalog or portal policies lifecycle decisions
+```
+
+This separation prevents two common design mistakes. First, sending traffic
through a gateway does not establish an API lifecycle process. Second, adopting
a large management platform does not remove the need to design and operate the
runtime gateway carefully.
+
+## Where Their Capabilities Overlap
+
+### Access and Consumer Policies
+
+A gateway can authenticate requests, associate credentials with consumers, and
enforce limits. An API management program defines how consumers are approved,
how credentials are issued and rotated, which service levels apply, and how
access is revoked. The gateway implements the runtime part of that policy.
+
+### Analytics
+
+A gateway can produce request counts, latency, status codes, route
information, and consumer identifiers when the relevant telemetry is
configured. API management may enrich that data with API ownership, plans,
business context, adoption funnels, or product-level reporting. Gateway
telemetry is an input, not a complete business analytics system.
+
+### Governance
+
+A gateway can enforce runtime controls consistently across configured APIs.
Broader governance also covers design standards, ownership, contract
compatibility, documentation, exceptions, and deprecation. A policy that is
never translated into a design check, deployment gate, or runtime rule remains
difficult to enforce.
+
+### Developer Experience
+
+A gateway exposes stable endpoints and applies access policies, but consumer
onboarding often requires additional capabilities: documentation, searchable
API discovery, application registration, credential workflows, and support
processes. Those functions may be provided by an API portal or assembled from
existing developer tooling.
+
+## When an API Gateway Is Enough
+
+A focused gateway may be sufficient when:
+
+- The primary need is to route and secure internal or service APIs.
+- API ownership and documentation already live in established engineering
systems.
+- Consumers are known teams rather than a large external developer community.
+- Existing identity, CI/CD, observability, and catalog tools cover lifecycle
needs.
+- The organization prefers composable open-source infrastructure over a
bundled platform.
+- Platform engineers need direct control over deployment topology and runtime
policies.
+
+"Enough" does not mean the lifecycle work disappears. It means the
organization has decided to handle that work through process and complementary
tools instead of one API management product.
+
+## When Broader API Management Is Needed
+
+Consider a broader API management program when:
+
+- Many teams publish APIs and need shared design and ownership standards.
+- Partners or external developers need self-service discovery and onboarding.
+- APIs are managed as products with plans, entitlements, service levels, or
monetization.
+- Compliance requires formal approvals, traceable exceptions, and lifecycle
evidence.
+- API versions and deprecations must be coordinated across many consumers.
+- Business stakeholders need adoption and product analytics beyond runtime
metrics.
+- Multiple gateways or environments need a consistent organizational control
model.
+
+These needs do not dictate a single product architecture. Teams can select an
integrated platform or combine a gateway with contract tooling, a catalog, a
portal, identity systems, analytics, and workflow automation.
+
+## Why Teams Often Need Both
+
+The gateway and management layer work best when their responsibilities are
explicit:
+
+1. API owners define a contract, owner, audience, and lifecycle state.
+2. Automated checks validate the contract and organizational standards.
+3. Approved API configuration is deployed to the gateway.
+4. The gateway enforces runtime policies and emits telemetry.
+5. Management systems use that evidence to monitor adoption, risk, and
lifecycle decisions.
+6. Policy or contract changes return through review and deployment instead of
being edited ad hoc in production.
+
+This model lets each layer do what it is designed for. Lifecycle systems
remain outside the latency-sensitive request path, while the gateway turns
approved runtime policy into repeatable traffic behavior.
+
+## Where Apache APISIX Fits
+
+[Apache APISIX](/) is an open-source API gateway. It provides the runtime
layer rather than a complete API management suite.
+
+APISIX [Routes](/docs/apisix/terminology/route/) match requests and run
configured plugins before forwarding traffic to upstream services.
[Services](/docs/apisix/terminology/service/) let related routes share upstream
and plugin configuration. [Consumers](/docs/apisix/terminology/consumer/)
identify API callers, [Credentials](/docs/apisix/terminology/credential/) hold
consumer authentication configurations, and [Consumer
Groups](/docs/apisix/terminology/consumer-group/) share reusable p [...]
+
+Teams can reuse plugin configurations across routes with [Plugin
Configs](/docs/apisix/terminology/plugin-config/) and apply plugins globally
with [Global Rules](/docs/apisix/terminology/global-rule/). The [Admin
API](/docs/apisix/admin-api/) manages these runtime resources in traditional
and decoupled deployment modes. Authentication, rate limiting, logging,
metrics, and traffic-control plugins supply enforcement and evidence for APIs
routed through APISIX.
+
+APISIX does not, by itself, replace organization-wide design review, a
source-of-truth API catalog, a developer portal, product subscription
workflows, or lifecycle approval processes. Teams that need those capabilities
integrate APISIX with the tools responsible for them.
+
+## Selection Checklist
+
+Use these questions to define the required scope before comparing products:
+
+1. Do you need runtime traffic control, lifecycle coordination, or both?
+2. Are the API consumers internal teams, partners, public developers, or a mix?
+3. Where are API contracts, ownership, and lifecycle state recorded today?
+4. Which runtime policies must be consistent across routes, teams, or
environments?
+5. Do consumers need self-service discovery, registration, or credential
issuance?
+6. Is gateway telemetry sufficient, or do you need business-level API
analytics?
+7. Are monetization, entitlements, and billing part of the API program?
+8. Which controls must be automated in design review, CI/CD, and runtime?
+9. Do you prefer an integrated platform or composable tools with clear
interfaces?
+10. Who owns each layer after launch, including exceptions and deprecations?
+
+The answers usually make the category decision clearer. Choose a gateway for
runtime policy enforcement. Build or adopt API management capabilities when the
organizational and lifecycle requirements extend beyond the request path.
diff --git a/website/learning-center/api-governance.md
b/website/learning-center/api-governance.md
new file mode 100644
index 00000000000..bfb28e4b649
--- /dev/null
+++ b/website/learning-center/api-governance.md
@@ -0,0 +1,199 @@
+---
+title: "API Governance: Framework and Best Practices"
+description: "Learn how API governance aligns ownership, design standards,
security, lifecycle controls, runtime enforcement, and evidence across API
teams."
+slug: api-governance
+date: 2026-08-20
+tags: [api-governance, api-management, api-security]
+hide_table_of_contents: false
+---
+
+API governance is the system of decision rights, standards, processes, and
controls that helps an organization operate APIs consistently throughout their
lifecycle. It defines who owns an API, which rules apply, how exceptions are
approved, where controls are enforced, and what evidence shows that the rules
are working.
+
+Governance is broader than installing an API gateway or publishing a style
guide. Effective governance connects design-time checks, delivery workflows,
runtime policy enforcement, and lifecycle decisions. It should reduce avoidable
risk and inconsistency without turning every API change into a centralized
manual review.
+
+## API Governance vs API Management and API Gateways
+
+These concepts overlap, but they are not interchangeable.
+
+| Concept | Primary purpose | Typical responsibilities |
+|---|---|---|
+| API governance | Define decision rights, standards, controls, exceptions,
and accountability | Ownership, design rules, security baselines, versioning,
review, evidence, and retirement |
+| API management | Operate APIs across their lifecycle | Design, publication,
discovery, onboarding, analytics, governance, and runtime control, depending on
the platform |
+| API gateway | Enforce policies on live traffic | Routing, authentication,
rate limiting, transformation, traffic control, metrics, and logging |
+
+Governance describes what should happen and who is accountable. API management
supplies processes and tooling for running the program. The gateway implements
selected runtime controls. For a fuller explanation of the product categories,
see [API gateway vs API
management](/learning-center/api-gateway-vs-api-management/).
+
+## Why API Governance Matters
+
+As an API estate grows, local decisions accumulate. Teams may use different
authentication methods, error formats, versioning rules, and deprecation
practices. Ownership becomes unclear, duplicate APIs appear, and consumers
discover breaking changes only after deployment.
+
+Governance addresses these problems by establishing a small set of shared
expectations:
+
+- Every API has an accountable owner and intended audience.
+- Contracts follow agreed naming, compatibility, and documentation standards.
+- Security controls reflect data sensitivity and exposure.
+- Runtime policies are applied consistently to the APIs that require them.
+- Changes, exceptions, and deprecations are traceable.
+- Teams collect evidence that controls operate as intended.
+
+The purpose is not uniformity for its own sake. Standards should target risks
and coordination costs that individual teams cannot solve independently.
+
+## Design-Time and Runtime Governance
+
+### Design-Time Governance
+
+Design-time governance applies before an API reaches production. It can
include:
+
+- Reviewing an API's purpose, owner, consumers, and data classification
+- Describing the interface with an [OpenAPI
specification](https://spec.openapis.org/oas/latest.html) or another
appropriate contract format
+- Linting names, error models, pagination, versioning, and compatibility rules
+- Running schema, security, and dependency checks in CI
+- Requiring an explicit exception when a standard cannot be met
+- Publishing the approved contract and ownership metadata to a catalog
+
+These controls catch problems while they are less expensive to change. They
also create inputs for documentation, testing, client generation, and
deployment automation.
+
+### Runtime Governance
+
+Runtime governance applies while consumers use an API. Common controls include:
+
+- Authenticating callers and validating credentials
+- Enforcing shared access, network, and TLS policies
+- Applying consumer, route, or global rate limits
+- Restricting methods, paths, origins, or source addresses
+- Routing traffic between approved versions or deployments
+- Capturing request metrics and access logs
+- Detecting policy violations and operational anomalies
+
+A gateway is useful here because it can enforce common controls without
duplicating them in every backend. It cannot, however, correct an ambiguous
contract, assign an API owner, or decide whether a breaking change should be
approved.
+
+### Lifecycle Governance
+
+Lifecycle governance connects design and runtime. It defines when an API moves
from proposed to active, deprecated, and retired; how consumers are notified;
which compatibility guarantees apply; and how teams verify that old versions
are no longer in use.
+
+## An API Governance Framework
+
+A practical framework covers the following areas.
+
+### 1. Ownership and Inventory
+
+Record an accountable owner, technical contact, intended consumers, lifecycle
state, and critical dependencies for each API. An inventory should answer which
APIs exist and who can make decisions about them. A repository file, service
catalog, or API catalog can hold this information, but it needs a maintained
source of truth.
+
+### 2. Design and Contract Standards
+
+Define the minimum rules that improve interoperability: resource naming,
status codes, error formats, pagination, idempotency, compatibility, and
contract documentation. Automate objective rules with linters and tests.
Reserve human review for architecture, domain modeling, risk, and exceptions
that tools cannot evaluate reliably.
+
+### 3. Security and Data Policy
+
+Classify APIs by exposure and data sensitivity, then map each class to
required controls. A public read-only API and an internal payment API should
not inherit an identical checklist. Policies may cover authentication,
authorization boundaries, encryption, input validation, rate limiting, secrets,
logging, and retention.
+
+Gateway authentication is only one layer. Backend services must still enforce
resource ownership and business authorization, while development and security
practices address vulnerabilities that cannot be detected at the gateway.
+
+### 4. Change and Version Management
+
+Define what counts as a breaking change, how compatibility is tested, when a
new version is required, and how long old versions are supported. Track
consumers of a version before deprecation. A versioning standard without usage
evidence can leave teams unable to retire anything safely.
+
+### 5. Publication and Consumer Experience
+
+An approved API should have accurate documentation, a clear support channel,
and a predictable onboarding process. Public and partner APIs may also need
searchable discovery, application registration, credentials, service-level
expectations, and change notifications. These are usually handled outside the
gateway.
+
+### 6. Runtime Policy Enforcement
+
+Translate approved policies into deployable configuration. Reusable policy
bundles reduce drift, while environment-specific configuration handles
legitimate differences. Treat gateway configuration as code where possible,
review it, test it, and promote it through environments instead of relying on
untracked production edits.
+
+### 7. Observability and Evidence
+
+Define which signals demonstrate that an API and its controls are healthy.
Gateway metrics can show request volume, latency, errors, and policy outcomes
for traffic that passes through the gateway. Logs can support investigations
and compliance evidence when their content, retention, access, and privacy
controls are designed appropriately.
+
+Gateway telemetry complements service metrics, distributed tracing, security
monitoring, and business events. It does not provide complete end-to-end or
business visibility on its own.
+
+### 8. Deprecation and Retirement
+
+Set entry and exit criteria for deprecation. Identify active consumers,
communicate dates, monitor remaining traffic, and remove routes, credentials,
documentation, and dependencies when retirement is complete. Keeping abandoned
endpoints indefinitely increases attack surface and operational cost.
+
+## Centralized vs Federated API Governance
+
+### Centralized Governance
+
+A central platform or architecture team defines standards and reviews changes.
This can create consistency quickly, but a small team may become a queue for
every API decision. Centralized review is most useful for high-risk decisions,
shared platform controls, and organization-wide exceptions.
+
+### Federated Governance
+
+Domain teams own their APIs within shared organizational guardrails. Automated
checks and reusable runtime policies enforce the common baseline, while teams
retain authority over domain-specific design. A central group maintains
standards, tooling, and exception policy rather than approving every routine
change.
+
+Many organizations use a hybrid model: centralized minimum controls with
federated API ownership. The right balance depends on regulatory risk, team
maturity, API audience, and the cost of inconsistency.
+
+## API Governance Process
+
+The following sequence turns governance from a document into operating
practice:
+
+1. **Inventory APIs and assign owners.** Start with externally exposed and
business-critical APIs rather than waiting for a perfect enterprise inventory.
+2. **Classify APIs by risk and audience.** Use the classification to select
proportionate controls.
+3. **Define a minimum baseline.** Choose a short set of design, security,
documentation, and lifecycle rules that can be explained and measured.
+4. **Automate design checks.** Run contract linting, compatibility checks, and
security tests in CI where possible.
+5. **Create reusable runtime policies.** Package common gateway controls so
teams do not recreate them route by route.
+6. **Manage exceptions explicitly.** Record the owner, reason, compensating
control, approval, and expiry date.
+7. **Collect evidence.** Monitor API health, policy outcomes, configuration
drift, undocumented APIs, and deprecated-version traffic.
+8. **Review outcomes and revise standards.** Remove rules that add work
without reducing risk, and strengthen controls where incidents or drift reveal
a gap.
+
+## API Governance Tools
+
+No single tool governs an API estate by itself. Common tool categories include:
+
+| Tool category | Governance role |
+|---|---|
+| Contract and design tools | Define and review API interfaces |
+| Linters and CI checks | Automate objective design and compatibility rules |
+| Service or API catalogs | Record ownership, lifecycle state, documentation,
and dependencies |
+| Source control and delivery systems | Review, approve, test, and promote
changes |
+| Identity and secrets systems | Manage users, applications, credentials, and
trust material |
+| API gateways | Enforce selected runtime policies and route traffic |
+| Observability and SIEM systems | Analyze operational and security evidence |
+| Workflow systems | Track exceptions, deprecations, and organizational
approvals |
+
+Evaluate tools against a defined governance process. Buying a portal or
gateway before establishing ownership and decision rights often moves the
inconsistency into a new interface instead of resolving it.
+
+## How Apache APISIX Supports Runtime API Governance
+
+[Apache APISIX](/) can serve as the runtime enforcement component in a wider
governance architecture.
+
+- [Routes](/docs/apisix/terminology/route/) and
[Services](/docs/apisix/terminology/service/) define how requests reach
upstream APIs and which plugins run.
+- [Plugin Configs](/docs/apisix/terminology/plugin-config/) let multiple
routes reuse a plugin configuration.
+- [Global Rules](/docs/apisix/terminology/global-rule/) run configured plugins
before route- or service-level plugins, which can support selected gateway-wide
controls.
+- [Consumers](/docs/apisix/terminology/consumer/) identify API callers,
[Credentials](/docs/apisix/terminology/credential/) hold consumer
authentication configurations, and [Consumer
Groups](/docs/apisix/terminology/consumer-group/) apply reusable plugin
policies to sets of consumers.
+- Authentication, IP restriction, rate limiting, and transformation plugins,
together with [SSL and mTLS configuration](/docs/apisix/mtls/), enforce
controls on traffic routed through APISIX.
+- [Prometheus metrics](/docs/apisix/plugins/prometheus/) and logging plugins
such as [http-logger](/docs/apisix/plugins/http-logger/) export runtime
evidence to external monitoring and analysis systems.
+- The [Admin API](/docs/apisix/admin-api/) manages APISIX runtime resources in
deployment modes that use it, enabling teams to connect reviewed configuration
workflows to the gateway.
+
+These mechanisms do not make APISIX a complete governance system. APISIX does
not assign organizational ownership, approve API designs, maintain a
source-of-truth catalog, provide a complete developer portal, or run lifecycle
approval workflows. Those responsibilities stay with API owners and the
connected tools selected by the organization.
+
+## API Governance Best Practices
+
+- Keep the mandatory baseline small enough to explain, automate, and maintain.
+- Apply controls according to API risk instead of forcing every API through
the same process.
+- Store ownership and lifecycle state in a maintained system of record.
+- Validate API contracts and compatibility before deployment.
+- Treat gateway policies as reviewed, tested configuration rather than manual
production settings.
+- Separate gateway authentication from application-level business
authorization.
+- Use reusable policies, but allow documented exceptions with owners and
expiry dates.
+- Monitor whether controls are deployed and effective, not only whether a
policy document exists.
+- Include privacy and retention requirements when collecting API logs.
+- Measure deprecated-version traffic before removing an endpoint.
+- Review governance rules after incidents, platform changes, and repeated
exception requests.
+
+## API Governance Checklist
+
+For each production API, confirm that:
+
+- An accountable owner and support contact are recorded.
+- The audience, data classification, and lifecycle state are known.
+- A reviewed contract describes the current interface.
+- Automated checks cover applicable design and compatibility rules.
+- Authentication and authorization responsibilities are documented.
+- Required gateway policies are deployed through a controlled workflow.
+- Secrets and certificates have owners and rotation procedures.
+- Metrics, logs, and alerts cover the expected operational risks.
+- Exceptions include a reason, owner, compensating control, and expiry date.
+- Versioning, deprecation, consumer notification, and retirement paths are
defined.
+
+Governance becomes useful when these answers are visible and actionable to the
teams building and operating APIs. The goal is a dependable system of ownership
and controls, not a longer approval checklist.
diff --git a/website/learning-center/apisix-vs-apigee.md
b/website/learning-center/apisix-vs-apigee.md
index 0404bae1907..ece055fc1e2 100644
--- a/website/learning-center/apisix-vs-apigee.md
+++ b/website/learning-center/apisix-vs-apigee.md
@@ -36,7 +36,7 @@ APISIX is a **gateway**. It excels at routing,
authentication, rate limiting, tr
Apigee is a **platform**. It includes a gateway, but its value proposition
extends to the full API business: onboarding external developers through a
portal, analyzing API usage for product decisions, monetizing APIs, and
governing them across their lifecycle.
-This means the comparison is rarely feature-for-feature. The real question is
whether you need a focused, high-performance gateway you can run anywhere, or
an end-to-end managed API management suite, and whether you are willing to
trade cost and portability for that breadth.
+This means the comparison is rarely feature-for-feature. The real question is
whether you need a focused, high-performance gateway you can run anywhere, or
an end-to-end managed API management suite, and whether you are willing to
trade cost and portability for that breadth. See [API gateway vs API
management](/learning-center/api-gateway-vs-api-management/) for a
vendor-neutral breakdown of these categories.
## Architecture and Deployment
diff --git a/website/learning-center/what-is-an-api-gateway.md
b/website/learning-center/what-is-an-api-gateway.md
index aa05ac7fdb4..128888d3f8e 100644
--- a/website/learning-center/what-is-an-api-gateway.md
+++ b/website/learning-center/what-is-an-api-gateway.md
@@ -120,7 +120,7 @@ In practice, many organizations start with a reverse proxy
or load balancer and
### API Gateway vs API Management
-An API gateway is the runtime component on the request path. It routes traffic
and enforces policies. API management is the broader lifecycle discipline and
may also include API design, publishing, documentation, developer onboarding,
analytics, and governance. A gateway can be part of an API management platform,
but the two terms are not interchangeable.
+An API gateway is the runtime component on the request path. It routes traffic
and enforces policies. API management is the broader lifecycle discipline and
may also include API design, publishing, documentation, developer onboarding,
analytics, and governance. A gateway can be part of an API management platform,
but the two terms are not interchangeable. The [API gateway vs API management
guide](/learning-center/api-gateway-vs-api-management/) compares their
responsibilities and explain [...]
## API Gateway Use Cases
diff --git a/website/src/pages/comparisons.tsx
b/website/src/pages/comparisons.tsx
index 0695f7a55c7..0ee8b153c35 100644
--- a/website/src/pages/comparisons.tsx
+++ b/website/src/pages/comparisons.tsx
@@ -62,6 +62,12 @@ const COMPARISONS: Comparison[] = [
'How an API gateway and a load balancer differ, where they overlap, and
when to use each.',
to: '/learning-center/api-gateway-vs-load-balancer/',
},
+ {
+ title: 'API gateway vs API management',
+ description:
+ 'Runtime traffic control vs the broader API lifecycle, and when an
organization needs both.',
+ to: '/learning-center/api-gateway-vs-api-management/',
+ },
{
title: 'Kubernetes API gateway',
description:
diff --git a/website/static/llms.txt b/website/static/llms.txt
index fe83aaa1fa3..1e688d3a794 100644
--- a/website/static/llms.txt
+++ b/website/static/llms.txt
@@ -48,6 +48,8 @@
## Learning Center
- [What is an API
Gateway?](https://apisix.apache.org/learning-center/what-is-an-api-gateway/):
Definition, benefits, and use cases
+- [API Gateway vs API Management: Key
Differences](https://apisix.apache.org/learning-center/api-gateway-vs-api-management/):
Runtime gateway capabilities compared with full API lifecycle management
+- [API Governance: Framework and Best
Practices](https://apisix.apache.org/learning-center/api-governance/):
Design-time and runtime governance, operating models, and implementation
practices
- [API Gateway Authentication: Methods, Best Practices &
Implementation](https://apisix.apache.org/learning-center/api-gateway-authentication/):
Auth at gateway layer (JWT, OAuth2, mTLS, HMAC)
- [API Gateway for Microservices: Architecture, Patterns & Best
Practices](https://apisix.apache.org/learning-center/api-gateway-for-microservices/):
Microservices architecture with API gateway
- [API Gateway Rate Limiting: Algorithms, Strategies &
Configuration](https://apisix.apache.org/learning-center/api-gateway-rate-limiting/):
Token bucket, sliding window, leaky bucket
