Adding policy-based capabilities to an API proxy is a two-step process:
- Configure an instance of a policy type.
- Attach the policy instance to a Flow.
The diagram below shows the relationship between policies and Flows. As you can see, a policy is attached to a Flow as a processing "Step". To configure the desired behavior for your API, you need to understand a little bit about Flows. (This topic was covered earlier in Configuring flows.)
One type of policy that is commonly used is SpikeArrest. SpikeArrest prevents sudden increases in message traffic that might swamp your backend services.
Attaching a policy to a flow
To attach a policy to a Flow:
- Select an API proxy and navigate to the Develop view.
- In the API Proxy Editor, select the flow to which you want to attach a policy in the
For example, the PreFlow flow is selected for the default API proxy endpoint in the following figure:
- In the Design view, click +Step associated with the request or response
flow to attach a policy. For example:
The Add Step dialog opens displaying a categorized list of policies.
- Scroll and select the policy type that you want to attach to the selected flow.
- Modify the following fields.
Display Name: Unique display name for the policy. The UI will generate a default name, but it is advisable to create a descriptive name for the policy. This will ensure that other developers in your organization have an easy time understanding what the policy is intended to do.
Name: Unique name for the policy. The policy name matches the display name with the following exceptions:
Spaces are replaced by dashes.
Consecutive dashes are replaced by a single dash.
Except for dashes, underscores, and spaces (which are replaced, as noted above), characters that are not alphanumeric, such as pound signs, percent signs, ampersands, and so on, are removed.
- Click Add.
The policy is attached to the selected flow.
After the policy is attached, you’ll see the policy displayed in the Designer view for the flow, in this example the PreFlow of the default proxy endpoint, and in the Policies list in the Navigation pane. The Code view, which displays the XML for the newly attached policy, displays below the Designer view. Edge generates an instance of the policy that contains a set of reasonable default values.
Adding a policy without attaching it to a flow
To add a policy without attaching it to a flow, which is useful for Handling faults, click + in the Policies bar in the Navigator view to open the Add Policy dialog and add the policy (as described in steps 4 through 6 in the previous section).
A policy that is not attached to any flow is flagged with the "detached" icon in the Policies list, as shown adjacent to the API key message policy shown in the previous figure.
After you create the policy, you can attach it to a flow by dragging and dropping it from the Policies list to the desired flow in the Designer view.
Detaching policies from a flow
To detach a policy from a Flow, select the Flow. Mouse over the icon for the policy in the Designer view of the Flow. Click the X in the circle that appears in the icon.
Deleting a policy instance
To delete a policy instance, mouse over the entry for the policy in the Navigator view. Click the X in the circle that appears to the right of the entry.
Configuring policies in the management UI
When the UI generates a policy instance, it applies reasonable default values for common settings. You may need to modify these settings to meet your requirements.For example:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <SpikeArrest async="false" continueOnError="false" enabled="true" name="spikearrest-1"> <DisplayName>SpikeArrest-1</DisplayName> <FaultRules/> <Properties/> <Identifier ref="request.header.some-header-name"/> <MessageWeight ref="request.header.weight"/> <Rate>30ps</Rate> </SpikeArrest>
You can configure a policy by directly editing its XML configuration in the
Code view. For example, the peak message rate for the Spike Arrest policy is
initially set to 30 messages per second. You can change the peak rate by changing the
Rate> element value in the XML for the policy. For further details about
configuring policies, see the Policy Reference.
You can also cut-and-paste policies into the Code view. This is a great way to re-use policies from the samples available on GitHub.
When you make changes to a policy definition in the Code view, the changes are reflected in the Property Inspector. The reverse is also true — make changes in the Property Inspector and they appear in the XML in the Code view.
For documentation specific to the Quota policy used in this topic, see Quota policy.