Lesson 2 of 5
Providers and proxies
9 min
Listen to this lesson
Two objects carry most of the work in API Management. An API provider describes how to reach a backend system. An API proxy is the API consumers actually call: its own URL, its own policies, forwarding to a target through a provider. Keeping them separate means the same backend connection serves many proxies, and a backend move changes one provider instead of every API.
API providers
SAP's tutorials describe the API provider as the object that abstracts the connection to the backend. When you create one you choose how the backend is reached. Depending on your tenant, the options typically cover systems on the internet, on-premise systems reached through SAP Cloud Connector, Open Connectors and Cloud Integration. For an SAP Gateway backend you can also set the catalog path, so you can discover the backend's services and create proxies from them instead of typing URLs.
| Backend | Provider connection | Contoso example |
|---|---|---|
| S/4HANA in the private network | On-premise, through Cloud Connector, with the location set | CMP's sales order OData services |
| Public SaaS or partner service | Internet, with TLS and the partner's credentials | A carrier's shipment tracking API |
| An integration flow | Cloud Integration endpoint | A flow that combines order status with delivery tracking |
| Third-party SaaS with a prebuilt connector | Open Connectors | A CRM used by Contoso's aftermarket sales team |
API proxies
An API proxy has a base path on a host alias, for example /contoso/orderstatus/v1 on Contoso's API domain, and a target endpoint that points to the backend through a provider. You can create a proxy by discovering a service on a provider, by pointing at a URL, or from an OpenAPI definition in the API designer. SAP's tutorial flow is short: choose the provider, discover the service, create, save, deploy. The proxy is not callable until it is deployed.
- Consumer calls the proxyGET /contoso/orderstatus/v1/orders?customerPO=GLF-PO-55120 with an API key header.
- Proxy endpointPolicies check the key, apply traffic limits and validate the request.
- Target endpointPolicies add backend credentials and translate the request.
- ProviderRoutes the call through Cloud Connector to CMP's sales order service.
- Response backOrder 1000457 status, shaped and filtered for the customer, with analytics recorded.
Versioning and naming
- Put the major version in the base path (
/v1) and never make a breaking change inside it: removing a field, renaming one, or changing a type breaks consumers. - Additive changes, such as a new optional field, can stay in the same version; announce them anyway.
- When a breaking change is needed, publish
/v2alongside/v1, give consumers a dated migration window, and watch analytics for v1 traffic before retiring it. - Name proxies by business capability, not backend technology:
OrderStatus, notAPI_SALES_ORDER_SRV_proxy.
What would you do?
Sam announces that CMP's sales order service will be reached through a new Cloud Connector location after a network change. Contoso has six API proxies using that backend. What is the cleanest way to handle the change?
- API providers hold backend connections; API proxies are what consumers call.
- Create proxies by discovering services, from a URL, or from an OpenAPI definition.
- Version in the base path and never break a published version.
- Shape errors and strip internal details so the proxy does not leak the backend.
Check your understanding · not graded
Lesson check
1. Which object abstracts the connection to a backend system?
2. How does an API proxy reach Contoso's on-premise S/4HANA system?
3. Which change can stay inside the same API version?
4. When can a consumer first call a newly created API proxy?