Identify API Policies for All Levels in the Application Network With API-Led Connectivity
A MuleSoft expert explores the API policies encouraged by Anypoint Platform and how to decide on which API policy best fits your development needs.
Join the DZone community and get the full member experience.
Join For FreeAgenda
- Visit the API policies encouraged out-of-the-box by Anypoint Platform.
- Decide on one Experience API, one Process API, and one System API from the APIs associated with the "Integration" product.
- For each of those APIs, pick all API policies that we would advocate applying to that API.
- Also specify the order for certain API policies.
- Are there any other API policies that we would want to apply?
Adopting Relevant API Policies for System APIs
Decided C4E establishes the following guidelines for defining API policies on System APIs:
- IP whitelisting to the IP address range of the API implementations of Process APIs (assuming they execute in a subnet that assigns well-defined origin IPs to them).
- Requirements should constantly define SLA tiers that require standard approval.
- SLA-based Rate Limiting API policy must enforce the QoS of the chosen SLA tier.
- Spike Control API policy must protect the backend system from acting API invocation bursts by evening them out and driving the published overall throughput guarantee.
- X-Rate-Limit HTTP response headers should not be presented to API clients from this API policy but from the SLA-based API policy.
These API policies should be applied in this order and thereby enforce the strict agreement for this critical class of APIs. Hotel management applies these guidelines to all System APIs in their application network.
Picking Suitable API Policies for Process APIs
Hotel Management C4E establishes the subsequent guidelines for setting API policies on Process APIs:
- IP whitelisting to the IP address range of the API implementations of Process APIs and Experience APIs (assuming they execute in a subnet that assigns well-defined source IPs to them).
- May define non-SLA-based API policies but should then use Client ID enforcement, such that the identification of API clients is always appreciated and analyses per API client can be performed.
- If SLA tiers are established, then SLA-based Rate Limiting API policy must enforce the QoS of the chosen SLA tier.
- Spike Control API policy must guard against temporary API invocation bursts by evening them out and enforcing the published overall throughput guarantee.
- X-Rate-Limit HTTP response headers should not be presented to API clients from this API policy.
These API policies should be applied in this order and Hotel Management applies these guidelines to all Process APIs in their application network.
Keeping Relevant API Policies for Experience APIs
API policies on Experience APIs change critically on the nature of the top-level API client for which an Experience API is intended. Hotel Management's C4E, therefore, first defines API policies for specific Experience APIs, simplifying to Hotel Management-wide guidelines in a second step.
For the "Booking Quote Creation EAPI" consumed by the Aggregator, you define the following:
- IP whitelisting to the IP address of the Aggregator to complement TLS mutual authentication.
- XML/JSON threat protection.
- One SLA tier for the required 1000 requests, which makes this SLA specific and provides monitoring and recording on the SLA.
- SLA-based Rate Limiting (not Spike Control).
- X-Rate-Limit HTTP response headers should not be disclosed to API clients from this API policy because API clients are external.
- No Spike Control API policy, to limit the resource consumption incurred by queuing requests.
Opinions expressed by DZone contributors are their own.
Comments