API management policies are an essential tool for managing your APIs efficiently. You can use them to enforce security, apply rate limiting, convert formats and more.
What are APIM policies?
API management (APIM) policies are all about enforcing behaviours. An APIM policy is a set of statements designed to run in a particular order during the API request and response process.
You can use API gateway policies to turn your gateway into an enforcement point for these. This allows you to apply policies across multiple regions while enjoying fine-grained control over single sign-on and role-based access control.
Benefits of API management policies
A well-thought-out API management policy can deliver multiple benefits:
- Enhanced security and efficiency: applying security at the API gateway policy level means you can enforce changes to API keys (or OAuth client IDs) en masse by modifying a single policy – rather than individual keys.
- Robust traffic management: manage traffic through policies to ensure your services aren’t overwhelmed
- Tiered access management: great when clients pay for different volumes of API calls.
Types of API management policies
APIM policy examples include:
- Security policies: these enable you to apply security at key level, user level and API level. You can manage access lists, enjoy granular control over method and path, set rate limits and quotas and add tags and metadata. Use partitioning to break down an API management policy so that only some elements apply to an API key.
- Rate limiting policies: use these to protect your API. You can apply a rate limit (and quota) to each user’s access to control traffic peaks (and volumes) to ensure positive performance by limiting the number of requests your API will accept within a specified period.
- Throttling policies: throttle traffic to deal with spikes in traffic efficiently and fairly. With a throttling policy, you can queue requests, specify the number of retries and set the delay between retries to optimise performance.
Depending on your chosen API management solution, you may also be able to use Open Policy Agent (OPA) to write custom rules. Considering Tyk as an example, you can control the behaviour of all dashboard APIs (except your public developer portal) and access rules, with the OPA rules sitting on top of your dashboard API.
API management policy components
It’s worth understanding some of the terminology you may encounter when using API management policies and/or OPA:
- Deny rules are the main building blocks for controlling access. They can return detailed and dynamic errors in the case of rejection.
- Patch requests enable you to modify requests and responses with a JSON merge patch format.
- Rego is a high-level declarative language used in OPA. It allows you to specify policy as code and use simple APIs to offload decision-making related to policies from your software. Using it means that your policies are easy to read and write.
How to monitor and troubleshoot API policies
It’s important to monitor and troubleshoot your policies to ensure the healthy functioning, performance and availability of your APIs.
- Use traffic management monitoring for a clear indication of whether the policies you’re using to shape your traffic are working as they should.
- Use real-time anomaly identification to spot potential security breaches and drive troubleshooting of any issues with your security policy.
Best practices for managing APIs with policies
Have a plan in place for what you intend to achieve by implementing APIM policies. Map out what you intend to achieve, how your API management contributes to that and the best practices you’ll be embracing. Examples of these include:
- Embracing OAuth2.0 and role-based access control as part of your security policy
- Aligning your rate limiting policy with different user tiers
- Using your policies to protect against distributed denial of service (DDoS) attacks and other threats
Remember: API management policies have the power to affect every single one of your users, so you need to get them right! This means thinking about which behaviours each policy will enforce and the level (API, user or key) at which it will enforce them.
While you’re here, why not check out some further thoughts on API governance, to ensure you’ve got everything covered?
