Shared flows - Interrupt flow

juanarias
Participant I

Hi,

is there a way to interrupt the flow in a shared flow, but not throwing a Fault?

I want to detect every HTTP OPTIONS request (to every proxy in my envinronment) and return a 200 OK code.

In this tutorial: https://docs.apigee.com/api-platform/develop/adding-cors-support-api-proxy

You use a "NoRoute" to prevent the flow to proceed to the target endpoint:

<RouteRulename="NoRoute">
  <Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition>
</RouteRule>

But if I want to replicate the same rule to multiple proxies, I need to multiplicate this configuration in each proxy.

Another possibility I can think of might be to redirect every OPTIONS request to a single proxy, that has this "NoRoute" and always returns 200 OK. But again, can this be done inside a shared flow?

Thanks in advance!

Juan Arias

Solved Solved
3 1 507
1 ACCEPTED SOLUTION

Good question. You cannot directly do what you describe.

I understand what you want and I think your question and your idea are reasonable.

Let's first explain why a simple sharedflow won't work (without RaiseFault) and then maybe look at some alternatives.

A sharedflow is just a sequence of policies. a FlowCallout is a single policy that says : call this reusable sequence of policies.

But in the sharedflow, there is no "request" and "response". It doesn't handle requests and responses. That's the job of the proxyendpoint. The sharedflow is just a sequence. As you point out in your question, the RaiseFault policy *can* short circuit the request and response handling, and can send back a response to a CORS OPTIONS request immediately. However, using RaiseFault to send a "normal" response may not be appropriate because you may not want to put the request into error state just to handle a valid OPTIONS request. It affects the analytics numbers - today, each RaiseFault counts as an error, even if you send back a 200.

As for other options, it might be nice to have some sort of inheritance... so that a proxy could implicitly inherit function from a parent proxy. If you had that, you could design each proxy to "inherit" from a base proxy that provides the CORS function you want. But Apigee Edge doesn't support that model today.

There are some possibilities

  • you can provide an standard "archetype" or template proxy for all of your teams, and then build a static analysis tool that checks to see that all proxies employ that template or comply to that model. This is essentially copy/paste , allowing for modifications in the OPTIONS response for each proxy.
  • you could build a root proxy that checks for and handles OPTIONS requests and then chains to, or otherwise connects to, all other proxies when the request is not OPTIONS. This requires that each of the other proxies does not listen directly on an exposed vhost.

I'm not sure which model I prefer. I think the OPTIONS is a real part of the API interface, and it seems like different APIs might want to enforce different restrictions on CORS, so I think I'd prefer that each proxy handle the OPTIONS request independently.

View solution in original post

1 REPLY 1

Good question. You cannot directly do what you describe.

I understand what you want and I think your question and your idea are reasonable.

Let's first explain why a simple sharedflow won't work (without RaiseFault) and then maybe look at some alternatives.

A sharedflow is just a sequence of policies. a FlowCallout is a single policy that says : call this reusable sequence of policies.

But in the sharedflow, there is no "request" and "response". It doesn't handle requests and responses. That's the job of the proxyendpoint. The sharedflow is just a sequence. As you point out in your question, the RaiseFault policy *can* short circuit the request and response handling, and can send back a response to a CORS OPTIONS request immediately. However, using RaiseFault to send a "normal" response may not be appropriate because you may not want to put the request into error state just to handle a valid OPTIONS request. It affects the analytics numbers - today, each RaiseFault counts as an error, even if you send back a 200.

As for other options, it might be nice to have some sort of inheritance... so that a proxy could implicitly inherit function from a parent proxy. If you had that, you could design each proxy to "inherit" from a base proxy that provides the CORS function you want. But Apigee Edge doesn't support that model today.

There are some possibilities

  • you can provide an standard "archetype" or template proxy for all of your teams, and then build a static analysis tool that checks to see that all proxies employ that template or comply to that model. This is essentially copy/paste , allowing for modifications in the OPTIONS response for each proxy.
  • you could build a root proxy that checks for and handles OPTIONS requests and then chains to, or otherwise connects to, all other proxies when the request is not OPTIONS. This requires that each of the other proxies does not listen directly on an exposed vhost.

I'm not sure which model I prefer. I think the OPTIONS is a real part of the API interface, and it seems like different APIs might want to enforce different restrictions on CORS, so I think I'd prefer that each proxy handle the OPTIONS request independently.