You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/api-management/api-management-howto-policies.md
+35-30Lines changed: 35 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,31 +1,36 @@
1
1
---
2
2
title: Policies in Azure API Management
3
-
description: Introduction to API Management policies, which change API behavior through configuration. Policy statements run sequentially on an API request or response.
3
+
description: Learn about API Management policies, which change API behavior through configuration. Policy statements run sequentially on an API request or response.
4
4
services: api-management
5
5
author: dlepow
6
6
7
7
ms.service: azure-api-management
8
8
ms.topic: concept-article
9
-
ms.date: 10/18/2023
9
+
ms.date: 05/13/2025
10
10
ms.author: danlep
11
11
12
+
#customer intent: As an API publisher, I want to learn about API Management policies so that I can use them to change API behavior.
In Azure API Management, API publishers can change API behavior through configuration using *policies*. Policies are a collection of statements that are run sequentially on the request or response of an API. API Management provides more than 50 policies out of the box that you can configure to address common API scenarios such as authentication, rate limiting, caching, and transformation of requests or responses. For a complete list, see [API Management policy reference](api-management-policies.md).
20
+
In Azure API Management, API publishers can change API behavior through configuration by using *policies*. This article describes how to use policies.
21
+
22
+
Policies are a collection of statements that are run sequentially on the request or response of an API. API Management provides more than 75 policies out of the box that you can configure to address common API scenarios like authentication, rate limiting, caching, and transformation of requests or responses. For a complete list, see [API Management policy reference](api-management-policies.md).
18
23
19
24
Popular policies include:
20
25
21
-
* Format conversion from XML to JSON
22
-
* Call rate limiting to restrict the number of incoming calls from a developer
23
-
* Filtering requests that come from certain IP addresses
26
+
* Format conversion from XML to JSON.
27
+
* Call rate limiting to restrict the number of incoming calls from a developer.
28
+
* Filtering of requests that come from certain IP addresses.
24
29
25
30
26
-
Policies are applied inside the gateway between the API consumer and the managed API. While the gateway receives requests and forwards them, unaltered, to the underlying API, a policy can apply changes to both the inbound request and outbound response.
31
+
Policies are applied inside the gateway between the API consumer and the managed API. Although the gateway receives requests and forwards them, unaltered, to the underlying API, a policy can apply changes to both the inbound request and the outbound response.
Policy definitions are simple XML documents that describe a sequence of statements to apply to requests and responses. To help you configure policy definitions, the portal provides these options:
31
36
@@ -34,7 +39,7 @@ Policy definitions are simple XML documents that describe a sequence of statemen
34
39
35
40
For more information about configuring policies, see [Set or edit policies](set-edit-policies.md).
36
41
37
-
The policy XML configuration is divided into `inbound`, `backend`, `outbound`, and `on-error` sections. This series of specified policy statements is executed in order for a request and a response.
42
+
The policy XML configuration is divided into `inbound`, `backend`, `outbound`, and `on-error` sections. This series of specified policy statements runs in order for a request and a response. Here's what it looks like:
38
43
39
44
```xml
40
45
<policies>
@@ -49,7 +54,7 @@ The policy XML configuration is divided into `inbound`, `backend`, `outbound`, a
49
54
<!-- statements to be applied to the response go here -->
50
55
</outbound>
51
56
<on-error>
52
-
<!-- statements to be applied if there is an error condition go here -->
57
+
<!-- statements to be applied if there's an error condition go here -->
53
58
</on-error>
54
59
</policies>
55
60
```
@@ -63,42 +68,42 @@ If an error occurs during the processing of a request:
63
68
* Execution jumps to the statements in the `on-error` section.
64
69
65
70
By placing policy statements in the `on-error` section, you can:
66
-
* Review the error using the `context.LastError` property.
67
-
* Inspect and customize the error response using the `set-body` policy.
71
+
* Review the error by using the `context.LastError` property.
72
+
* Inspect and customize the error response by using the `set-body` policy.
68
73
* Configure what happens if an error occurs.
69
74
70
75
For more information, see [Error handling in API Management policies](./api-management-error-handling-policies.md).
71
76
72
77
## Policy expressions
73
78
74
-
Unless the policy specifies otherwise, [policy expressions](api-management-policy-expressions.md) can be used as attribute values or text values in any of the API Management policies. A policy expression is either:
79
+
Unless the policy specifies otherwise, [policy expressions](api-management-policy-expressions.md) can be used as attribute values or text values in any of the API Management policies. A policy expression is one of the following:
75
80
76
-
*a single C# statement enclosed in `@(expression)`, or
77
-
*a multi-statement C# code block, enclosed in `@{expression}`, that returns a value
81
+
*A single C# statement enclosed in `@(expression)`
82
+
*A multi-statement C# code block, enclosed in `@{expression}`, that returns a value
78
83
79
84
Each expression has access to the implicitly provided `context` variable and an allowed subset of .NET Framework types.
80
85
81
86
Policy expressions provide a sophisticated means to control traffic and modify API behavior without requiring you to write specialized code or modify backend services. Some policies are based on policy expressions, such as [Control flow][Control flow] and [Set variable][Set variable].
82
87
83
88
## Scopes
84
89
85
-
API Management allows you to define policies at the following *scopes*, from most broad to most narrow:
90
+
API Management enables you to define policies at the following scopes, presented here from broadest to narrowest:
86
91
87
92
* Global (all APIs)
88
93
* Workspace (all APIs associated with a selected workspace)
89
94
* Product (all APIs associated with a selected product)
90
95
* API (all operations in an API)
91
-
* Operation (single operation in an API)
96
+
* Operation (a single operation in an API)
92
97
93
98
When configuring a policy, you must first select the scope at which the policy applies.
:::image type="content" source="media/api-management-howto-policies/policy-scopes.png" alt-text="Diagram that illustrates the five policy scopes." lightbox="media/api-management-howto-policies/policy-scopes.png":::
96
101
97
102
### Things to know
98
103
99
-
* For fine-grained control for different API consumers, you can configure policy definitions at more than one scope
100
-
* Not all policies are supported at each scope and policy section
101
-
* When configuring policy definitions at more than one scope, you control policy inheritance and the policy evaluation order in each policy section by placement of the `base` element
104
+
* For fine-grained control for different API consumers, you can configure policy definitions at more than one scope.
105
+
* Not all policies are supported at each scope and policy section.
106
+
* When configuring policy definitions at more than one scope, you control policy inheritance and the policy evaluation order in each policy section by placement of the `base` element.
102
107
* Policies applied to API requests are also affected by the request context, including the presence or absence of a subscription key used in the request, the API or product scope of the subscription key, and whether the API or product requires a subscription.
In API Management, a [GraphQL resolver](configure-graphql-resolver.md) is configured using policies scoped to a specific operation type and field in a [GraphQL schema](graphql-apis-overview.md#resolvers).
118
+
In API Management, a [GraphQL resolver](configure-graphql-resolver.md) is configured with policies scoped to a specific operation type and field in a [GraphQL schema](graphql-apis-overview.md#resolvers).
114
119
115
-
* Currently, API Management supports GraphQL resolvers that specify either HTTP API, Cosmos DB, or Azure SQL data sources. For example, configure a single [`http-data-source`](http-data-source-policy.md) policy with elements to specify a request to (and optionally response from) an HTTP data source.
116
-
* You can't include a resolver policy in policy definitions at other scopes such as API, product, or all APIs. It also doesn't inherit policies configured at other scopes.
117
-
* The gateway evaluates a resolver-scoped policy *after* any configured `inbound` and `backend` policies in the policy execution pipeline.
120
+
* Currently, API Management supports GraphQL resolvers that specify either HTTP API, Azure Cosmos DB, or Azure SQL data sources. For example, you can configure a single [`http-data-source`](http-data-source-policy.md) policy with elements to specify a request to (and optionally response from) an HTTP data source.
121
+
* You can't include a resolver policy in policy definitions at other scopes, such as API, product, or all APIs. The policy also doesn't inherit policies configured at other scopes.
122
+
* The gateway evaluates a resolver-scoped policy after any configured `inbound` and `backend` policies in the policy execution pipeline.
118
123
119
124
For more information, see [Configure a GraphQL resolver](configure-graphql-resolver.md).
120
125
@@ -138,16 +143,16 @@ Example policy definition at API scope:
138
143
</policies>
139
144
```
140
145
141
-
In the example policy definition above:
142
-
* The `cross-domain` statement would execute first.
143
-
* The [`find-and-replace` policy](find-and-replace-policy.md)would execute after any policies at a broader scope.
146
+
In the preceding example policy definition:
147
+
* The `cross-domain` statement runs first.
148
+
* The [`find-and-replace` policy](find-and-replace-policy.md)runs after any policies at a broader scope.
144
149
145
150
>[!NOTE]
146
-
> If you remove the `base` element at the API scope, only policies configured at the API scope will be applied. Neither product nor global scope policies would be applied.
151
+
> If you remove the `base` element at the API scope, only policies configured at the API scope will be applied. Policies configured at product and broader scopes won't be applied.
147
152
148
153
### Use policy expressions to modify requests
149
154
150
-
The following example uses [policy expressions][Policy expressions] and the [`set-header`](set-header-policy.md) policy to add user data to the incoming request. The added header includes the user ID associated with the subscription key in the request, and the region where the gateway processing the request is hosted.
155
+
The following example uses [policy expressions][Policy expressions] and the [`set-header`](set-header-policy.md) policy to add user data to incoming requests. The added header includes the user ID that's associated with the subscription key in the request, and the region where the gateway processing the request is hosted.
0 commit comments