SAP API management

API Management puts a managed layer in front of APIs: it applies security policies (authentication, rate limiting), transforms and routes calls, provides a developer portal for consumers, and monitors usage and performance. It lets you expose SAP (and other) APIs safely and at scale.

The distinction from an integration platform is worth being precise about, because the two get confused. Integration moves and transforms messages between systems, usually asynchronously and often on a schedule. API Management fronts a synchronous interface that somebody else calls. One is about getting data from A to B; the other is about exposing a service safely. A landscape often needs both.

• API proxies fronting backend services.
• Policies: security, rate limiting, transformation.
• Developer portal for API consumers.
• Analytics & monitoring of API usage.

The developer portal deserves separating from the rest, because it is what makes an API a product rather than an endpoint. It publishes the documentation, lets a consumer register an application and obtain a key without anybody being emailed, and shows them their own usage. Where APIs are exposed to partners, that self-service is most of the operational saving.

One more piece worth naming: API products. Individual API proxies are grouped into a product, and a consumer subscribes to the product rather than to each API. That is what makes tiered access possible, a basic product and a premium one with different quotas, and it is also the unit the developer portal presents. Designing products around what a consumer actually needs, rather than one per proxy, is what stops the portal becoming a list of endpoints.

A proxy that only forwards requests adds a hop. Policies are what make the layer worth having, and they are configuration attached to the request or response flow rather than code.

Security. Verify an API key, validate an OAuth token, check a JSON web token. The backend no longer needs to implement authentication for every consumer, and revoking one consumer is a change in one place.

Traffic management. Quota limits how many calls a consumer may make in a period. Spike arrest smooths bursts. Together they protect a backend that was never sized for whatever a consumer decides to do on a Monday morning.

Mediation. Convert between formats, rewrite paths, add or strip headers. This is how a backend can change its interface without every consumer changing with it.

Caching. Serve a repeated response without troubling the backend at all, which for reference data is the difference between thousands of calls and dozens.

Analytics. Who called what, how often, how fast, and how many errors. That data is usually the first thing anybody actually uses.

The pattern to recognise: each of these would otherwise be implemented in the backend, once per service, by whoever got there first.

Half an hour in a trial tenant, and it demonstrates the whole idea.

1. Take an existing OData service and create an API proxy in front of it.
2. Call the proxy. Same response as calling the service directly, and now it is going through the layer.
3. Add a verify API key policy. The same call now fails without a key, and succeeds with one, and the backend was not changed.
4. Add a quota policy of a few calls per minute. Exceed it deliberately and read the response.
5. Add a response cache and call twice. The second is faster and never reached the backend.
6. Look at the analytics. Calls, latency and errors, per consumer.

Step three is the point. Authentication moved out of the service, and every future consumer is onboarded by issuing a key rather than by changing code.

Use API Management when you expose APIs to many consumers (internal or external/partners) and need security, governance, throttling and analytics, rather than point-to-point calls. It is key to a scalable, secure API strategy.

The clearest signals that you need it: several consumers you do not control, external parties in particular; a backend that must be protected from load it cannot handle; a need to know who is calling what; or an interface you expect to change while consumers keep working. One internal consumer calling one service does not need a managed layer. See Cloud Integration for moving messages rather than fronting APIs, and SAP APIs for what is available to expose.

An API with consumers you do not control cannot change freely, and how that is managed is the difference between a managed API and a fragile one.

Breaking against non-breaking. Adding an optional field is safe, because a consumer ignoring it carries on. Removing a field, renaming one, changing a type or making something mandatory breaks anybody relying on the old shape. The rule that follows: add freely, never remove silently.

Where the version lives. Usually in the path, so a consumer calls version one explicitly and version two exists alongside it. That means running both for a period, which is the cost of not breaking anybody.

Deprecation with a date. Announce, keep both running, tell consumers when the old one stops, and use the analytics to see who is still calling it. That last part is why the managed layer helps: without it you are guessing who will break.

The proxy can absorb small changes. Where a backend field is renamed, a mediation policy can present the old name outward while the backend moves on, which buys time without a version bump.

The habit worth adopting from the start: version the API from day one, even with one consumer, because retrofitting a version scheme after the fact requires the change you were trying to avoid.

• What goes through it. External and partner-facing APIs, certainly. Internal system-to-system calls, usually not, because the layer adds a hop for no governance benefit.
• How consumers are onboarded. Self-service through a developer portal scales and needs the portal maintained. Manual issuing of keys is fine for a handful and does not scale.
• Where the quota sits. Per consumer protects the backend fairly. A single global limit protects it and lets one consumer starve the others.
• What is cached and for how long. Reference data, generously. Anything transactional, carefully or not at all.

• Wrong tool for the integration style.
• Ignoring monitoring/error handling.
• Point-to-point instead of governed integration.

• A proxy with no policies. It is an extra hop and a false sense of governance.
• Caching data that changes. Consumers then see stale values and the cause is invisible to them.
• No versioning strategy. The first breaking change breaks every consumer, which is what the layer existed to prevent. See Event Mesh and JDBC integration for the other styles.

• Policies added and never reviewed. A quota set for last year's volumes becomes the thing throttling this year's legitimate traffic.

Creating a proxy is the easy half, and designing the policies, versioning and onboarding so an API can be exposed safely to people you do not control is the part you do in the course.

The question that decides whether you need this at all: do you have consumers you do not control. If every caller is a system your team owns, the managed layer is overhead; the moment one is not, it is the thing that lets the backend change.