API Central Service concepts

AMPLIFY API Central Service is a next-generation API governance solution that provides:

  • Unified support for APIs with a consistent user experience.
  • Central, cloud-based governance with hybrid runtime deployment.
  • Self-service governance to support massive organizational adoption.

This topic introduces AMPLIFY API Central Service and its main themes and capabilities.

AMPLIFY API Central Service overview

This section provides a high-level introduction to AMPLIFY API Central Service.

AMPLIFY platform services

API Central Service is a fully integrated native service of the AMPLIFY platform. The AMPLIFY platform API Management services include:

  • API Builder service enables you to create APIs as Node.js applications that run on different cloud environments.
  • API Central Service consists of Software as a Service (SaaS)-based governance and SaaS/VPC/on-premise runtimes with basic API proxy and microgateway capability.
  • Policy management service enables you to extend basic proxy and microgateway with custom policies (API Central Service is a prerequisite).
  • API Portal is a re-brandable self-service portal for internal and ecosystem API consumers and API providers.
  • Search Service provides comprehensive analytics with machine learning, prebuilt data traceability for auditing, compliance, and troubleshooting.
  • Business Event Service provides streamlining of API provider and consumer registration, as well as API registration/consumption processes.

AMPLIFY API Management public cloud architecture

API providers expose APIs to their consumers. API consumers include internal development teams and external customers and partners. The API provider is an Axway customer and subscribes to the AMPLIFY platform. The API provider is a tenant of the AMPLIFY platform represented by a single organization. The API provider's users (for example, API developers registering APIs) are AMPLIFY platform users in that organization.

Manage access to API resources

API Central Service enables you to manage access to API-based resources. You can manage access to the following kinds of APIs using the HTTP/S protocol:

  • APIs developed using API Builder and deployed on the AMPLIFY platform.
  • APIs exposed by the pre-built Mobile Backend Services deployed on the AMPLIFY platform.
  • Remote APIs not on the AMPLIFY platform—exposed by cloud and/or on premise applications, or developed using third-party tools.

Cloud-based API governance

API Central Service provides a central, cloud-based, multi-tenanted API governance service on the AMPLIFY platform, which enables you to manage:

  • API proxies and API products
  • API consumers (teams and users) and client apps
  • Policies—policy library and policy profiles
  • OAuth authorization server

API proxy and policy configuration can be pushed from API Central Service governance to the API Central Service runtime to handle processing of requests. Configuration is cached locally at the runtime for performance and reliability. The runtime operates independently of API Central Service governance in case of connection outage.

Hybrid deployment

Enterprise customers are rapidly transitioning from on-premise to the cloud. Some are transitioning entirely to the cloud—both SaaS and customer-managed clouds. Others are transitioning to a hybrid of SaaS, customer-managed clouds, and on-premise. All customers are making this journey at varying speeds.

What does hybrid mean?

Hybrid deployment has multiple definitions:

  • Hybrid means working across SaaS, customer-managed cloud, and on-premise.
    • Existing applications remain on-premise, all new development is on the cloud
    • Re-hosting all on premise applications to the cloud over time
  • Hybrid means working across multiple cloud platforms because some customers have a multiple cloud platform strategy (for example, applications deployed on both Amazon Web Services and Microsoft Azure).
  • Hybrid means working with different types of applications on a single cloud platform:
    • Native—new applications developed using technology native to the cloud platform (for example, Amazon develop new applications using Lambda and expose as APIs using AWS API Gateway).
    • Lifted and shifted—on-premise applications moved as is to a cloud platform and then operate in context of cloud (auto-scaling, billing, and so on). This includes Infrastructure as a Service (IaaS) such as AWS, Azure, and GCP, or Platform as a Service (PaaS) in the cloud or on-premise such as OpenShift, Pivotal, or IBM Bluemix.

API Central Service supports these hybrid scenarios by enabling hybrid deployment of the API Central Service runtime (based on NGINX, API microgateway, and policy engine).

Supported runtime deployments

The API Central Service runtime supports the following deployments:

  • AMPLIFY platform public cloud
  • AMPLIFY platform dedicated cloud (VPC)
  • Customer managed clouds
  • On premise (container-based deployment)

API Central Service hybrid deployment architecture

Self-service API management

When API Gateways were originally deployed, a central team was responsible for all aspects of the gateway operation—registering APIs and services, developing and applying policies, testing, deploying into production, monitoring and troubleshooting, and analyzing usage patterns. API administrators were the superusers performing all tasks. This central single team approach will not organizationally scale to support the massive growth of API adoption by enterprises.

API Central Service provides self-service API management to enable the organizational scaling of API adoption. API Central Service provides a self-service model across all activities to push tasks to the people who own the activity.

Self-service API registration and publishing

This includes the following:

  • Enable API developers to register and apply policies to the APIs they develop and own
  • Extensible policy library—separation of policy development and policy application
  • Enable the governance team to control who is using what policies through team and user profiles

Self-service API administration

This includes the following:

  • Enable team admins to manage their own teams (teams can be external partners)
  • For internal APIs, enable API developers to administer consumption of APIs they develop and own
  • For B2B APIs, enable relationship managers to administer consumption of APIs by partners they are responsible for

Self-service API analytics and traffic monitoring

This includes the following:

  • API developers monitor and troubleshoot the APIs they develop (and only have access to their APIs and the traffic to their APIs)
  • Relationship managers monitor API consumption by their partners (and only have access to APIs used by their partners)
  • Instead of the central API team becoming a bottleneck for growth, they now become hands-off supervisors ensuring that the API Central Service is operating as required

API ecosystem enablement

API Central Service enables API providers to transition from a single API provider to an API broker to provide greater range of capabilities and value to API consumers.

Partners of the API provider can register their APIs as API proxies in the API provider’s API Central Service. API products combining APIs from the API provider and multiple partners can then be created. These combined API products can then be monetized, and the revenue shared with the partners.

API Central Service will also provide a branded developer portal allowing these partners to register their APIs in the API provider’s API Central Service.

API Central Service capabilities

This section explains the main API Central Service features such as API proxies, microgateways, API products, and policy management.

API proxies and microgateways

Access to APIs is managed using an API proxy. API consumers send requests to the API proxy, policies are applied, and the request is routed to the API.

Increasingly, API developers that are developing the API—whether using API Builder or a third-party tool—are responsible for the API proxy. Customers view the complete API as the combination of the API proxy and the API implementation. The API implementation and API proxy are developed together, versioned together, and deployed together.

API proxies are registered in API Central Service by importing the Swagger definition of the API and then applying policies. API proxy registration can be performed manually using the API Central ServiceI UI or automated using an API Central Service API.

API proxies

The API proxies page contains all the registered API proxies in API Central Service, and includes multiple API proxy versions, which are known as revisions. New API proxy revisions result from a change in the API implementation (for example, new methods added and Swagger reimported) or a change in the API proxy (for example, different policies applied).

API provider teams

API Central Service governance supports the concept of API provider teams that represent teams of API developers working on specific API projects. An API developer can be a member of multiple teams and work with API Central Service in the context of a single team at any one time. Access to API proxies in API Central Service is based on team membership. API developers can access the API proxies for the teams they are a member of, but not the API proxies of other teams.

API microgateways

API proxies in API Central Service are deployed to API microgateways in a specific environment. Promoting an API proxy from development through to production is in effect deploying the API proxy from API Central Service to the API microgateway in each runtime environment. Different API proxy revisions can be deployed in different runtime environments (for example, v1 in production and v2 in development).

Unified API creation and management

Because customers increasingly view the complete API as both the implementation and the proxy, the same API developer is increasingly responsible for both. Axway API Management provides unified API creation and management on the AMPLIFY platform:

  • Create the API implementation and proxy in the same design tools at the same time.
  • Deploy the API implementation and proxy to the same runtime to test.
  • Version the API implementation and proxy together in a Source Control Management (SCM) system.
  • Promote and deploy the API implementation and proxy together through to production.

Policy management

API governance policies are applied to an API proxy to control how requests are processed. API Central Service provides these basic API governance policies, which are applied to all API proxies and built into the API microgateway:

  • Authentication
  • Authorization
  • Rate limiting—throttling (to protect from overload) and quota (for monetization)

These basic API governance policies can be extended with custom policies developed using Policy Studio and executed by the policy engine (part of the API Central Service runtime).

The goal with custom policies is develop once, and use many times. A small team of policy developers will develop the policies using Policy Studio, and create an extensible library of policies. These policies will be applied to many API proxies registered by a large community of API developers who have no knowledge of policy development, with the ability to apply multiple policies to a single API proxy. This approach combines the powerful capability of custom policies with easy automated API proxy registration required for organizational scaling and adoption.

In addition, governance will be enforced using profiles to control what policies are applied to what APIs. For example, a profile may be created for a team of API developers so that all APIs registered by that team must have specific policies applied. Another common use case is a set of corporate security policies that must be applied to all APIs. A central governance team will define these profiles which are then enforced across a large community of API developers.

API products

API products provide a whole product-centric approach to exposing APIs to API consumers. API products package capabilities based on how the API is used by the API consumer instead of how it is implemented.

An API proxy has a provider-centric perspective—managing and securing access to an API. The API developer is responsible for the API proxy. The lifecycle of the API proxy is driven by the lifecycle of the API—new versions, deprecation, and retirement—and when the API developer makes changes to the API.

An API product has a consumer-centric perspective—how an API is exposed to and consumed by API consumers. The API product manager is responsible for the API product. The lifecycle of the API product is driven by when the API product manager wants to release offerings to API consumers.

API Central Service supports separate API proxy and API product lifecycles.

API product components

An API product consists of:

  • Bundle of individual methods from one or more API proxies. This bundle of methods defines an API that is exposed to API consumers.
  • Supporting materials to aid in the consumption of the API product and to take it to market. This includes how-to documentation, samples, marketing collateral, and so on.

API consumers access the API products that they are authorized for. Authorization is performed by team—which can be an internal API provider application development team, an external partner or a customer. In the API catalog of the developer portal, the application developers in that team will view the APIs defined by the authorized API products.

API catalog

The API catalog is the list of APIs that an API consumer is authorized to access. These APIs are the APIs exposed by the API products that the API consumer is authorized to access. The API consumer only views the exposed API methods and documentation, and not the internal details of the API product and API proxy.

The APIs in the API catalog include the fully qualified URLs of the deployed API proxy methods so that the API consumer can invoke the URL. These URLs are sourced from the deployed API proxy. The API Catalog view in API Portal is an example of a brandable API catalog. Similarly, the API Catalog view in API Manager is example of a simple, non-brandable API catalog.

APIs, API Proxies and API Products

Federated APIs and registry

API Central Service supports federated APIs and client registries across multiple runtime groups that can be distributed and partitioned in multiple ways:

  • AMPLIFY platform, customer-managed cloud, and on premise deployments
  • Multiple customer-managed clouds (for example, AWS and Microsoft Azure)
  • Multiple environments (for example, development, test, stage, and production)
  • Different administrative boundaries (for example, Europe and USA DMZ deployments managed by a on premise system administration team and an AWS deployment managed by a cloud system administration team)
  • Runtime partitioning of APIs—for example, partitioning by business unit, by channel (consumer, partner, agency, and so on), or by performance.

Runtime groups

A runtime group is a group of microgateways running the same API proxies for performance, scalability and high availability. Runtime groups apply to specific tenant organizations and are used to deploy multiple API proxies. For example:

Federated components

API Central Service can manage the following federated components across all runtime environments:

  • Federated API proxies enable you to manage all API proxies and provide a centralized deployment point with a DevOps-friendly API to deploy to different runtimes. You can deploy different API proxy revisions in different runtimes (for example, v1 in production, v2 in acceptance, and v3 in development). API Central Service also provides a consolidated view of what API proxies are deployed where across all runtimes.
  • Federated API products allow the API product manager to control the availability of API products in specific runtimes and the authorization of API consumers to access the API product in those runtimes. For example, while an API product may be made available in both production and staging environments, external API consumers are authorized to access the API product only in production, but internal API consumers can be authorized to access in both staging and production.
  • Federated API catalog provides API consumers with an aggregated view of all APIs they are authorized to access across all runtimes.
  • Federated registry manages all team, user, and application authentication and authorization across all APIs and across all runtimes.

Public APIs

A public API is an API product (more specifically the API exposed by an API product) for which an API consumer user can view the API documentation without authenticating on the API Portal. For example, the documentation of the following Twitter API can be viewed without logging in and authenticating with Twitter:

https://dev.twitter.com/overview/api

The API documentation of the public API must show the fully qualified URL for the methods in the API product. This means the public API is an API product that is available in a runtime group and exposing API proxies that are deployed in that runtime group.

This only applies to viewing the API documentation without user authentication on the API Portal. To invoke a public API, the application stills needs to be authenticated and authorized.

API Portal

The API provider is a tenant (organization) on the AMPLIFY platform and their API developers are AMPLIFY platform users. These users will log onto the AMPLIFY platform to develop APIs and manage API proxies.

In addition, API Central Service will provide a brandable API Portal for each tenant (organization) to support:

  • API consumers of the tenant (organization)—for example, external partners and customers of the tenant
  • API provider partners of the tenant (see API Central Service concepts)

These users are private to the API provider tenant and are not AMPLIFY platform users. These users might not even know that the API provider is using AMPLIFY platform to expose and manage their APIs. These users will need to log onto a tenant-branded API Portal and not standard AMPLIFY platform UIs. The tenant will want to brand the API Portal to support their digital initiatives.

The URL of the API Portal will also need to be tenant-specific. For example, if Acme Corp is the API provider tenant, they may want to expose the API Portal on api.acme.com/apiportal even though the API Portal is hosted on the AMPLIFY platform.

Related topics

API Central Service Getting Started

Related Links