API proxies manage request and response messages using a pipeline processing mode, where the pipeline consists of a sequence of flows. You attach Edge policies to different flows in the pipeline, depending on the type of policy and the action that you want to perform.
What are flows?
API proxies define request and response flows that are executed in a specific order. The order allows you to apply logic and behavior at specific points in the API proxy execution. The request and response flows are subdivided into proxy and target segments. Each segment is subdivided into the following flow 'stages':
- PreFlow: Always executes before any conditional flows.
- Conditional flows: One or more flows, each of which has an associated condition. Conditional flows tell Edge, "When you see this, perform this logic." For example, when an API call is a
/moviesresource (the condition), transform the response to JSON (through a policy attached to the conditional flow). Only one flow executes per transaction—the first flow whose condition evaluates to true.
In a conditional flow, the condition is evaluated in both the request and response. You cannot have separate conditions for request and response.
- PostFlow: Always executes after any conditional flows.
- PostClientFlow: An optional flow that executes after the response message has been sent to the requesting client app. (This is a specialized flow, and only MessageLogging policies can be attached to it.)
The following figure shows a basic request and response exchange between an app and a backend service. In this figure, the ProxyEndpoint and TargetEndpoint have been expanded to show the flows used to process the request and response:
This may look complicated, but it's fairly simple once you understand a few use cases. Flows are executed in the following order in both the Proxy Endpoint and the Target endpoint, first in the request, then in the response.
PreFlows always execute first, and the logic you attach in the PreFlow applies to all calls made to the API proxy. They are useful when you need to make sure that a policy or code executes before anything else happens. For example, you usually don't want an API proxy to waste any resources on an unauthenticated user. Also, you don't want to service an app that has exceeded its quota. To support these requirements, you put security and quota policies in the PreFlow segment. That way, you don't need to worry about a condition failing to evaluate. The policies will always execute before any other processing takes place.
2. Conditional Flow
API proxy programming starts to get interesting when you implement 'branching' logic for an API. For example, you might want to convert XML to JSON only when the requesting app is running on a mobile device; or create a new HTTP response header when the
/foo API resource is called; or you might want to return a targeted ad based on the data in the user's request. You can do this by setting up conditional flows.
As with PreFlow, the logic you attach to the PostFlow applies to all calls made to the API proxy. PostFlow is useful when you need to log some data, send a notification that something happened, transform the message format, and so on.
4. PostClientFlow (response only)
You can add an optional PostClientFlow to the ProxyEndpoint that executes after the response is returned to the requesting client app. Only MessageLogging policies can be attached to this flow. PostClientFlow reduces API proxy latency and makes information available for logging that is not calculated until after the response is sent, such as the
client.send.end.time. The flow is used primarily for measuring the time interval between the start and end timestamps for the response message. For more information, see the following:
- API proxy configuration reference
Help or comments?
- If something's not working: Ask the Apigee Community or see Apigee Support.
- If something's wrong with the docs: Send Docs Feedback
(Incorrect? Unclear? Broken link? Typo?)