What's the idiomatic way - multiple endpoints, multiple flows/resources, or routing rules?

[#1]

I'm looking to do something very simple, but I'm having trouble figuring out what the Apigee "idiomatic" way is for carrying it out.

Suppose I'm protecting a back-end API which has resources such as /api/v1/products and /api/v1/users. They all share the same base path /api/v1. And suppose the only thing I'm trying to do is pass through requests, subject to access control policies. Let's also assume that I don't need different access controls for the different resources. I also want to return a 404 if a request comes in for an endpoint that I haven't explicitly specified.

So do I want to create separate endpoints for /api/v1/products and /api/v1/users? That seems verbose.

Or do I create one endpoint for /api/v1 and put conditional flows underneath for suffixes matching /products and /users, and then a fall-through that matches everything else with a RaiseFault policy? That seems like the right thing, except that I'm not really doing anything inside the conditional flows. They're only there so that I can explicitly specify the resources to which I want to allow access.

Or do I create one endpoint for /api/v1 and put in separate routing rules for suffixes matching /products and /users? And if it's that, how do I configure the fall-through 404 case?

[ceber]

You've got it already, in my opinion. Here's how I'd tweak what you wrote.

I would create one endpoint for /api/v1 and put conditional flows underneath for suffixes matching /products and /users, and then a fall-through that matches everything else. In the fall-through I would put a RaiseFault policy to generate the 404. I wouldn't put any policies inside inside the conditional flows; they're there to explicitly specify the resources to which you want to allow access.

(I took out the "only" and "not really doing anything" bits. The conditional flows are doing something even if you don't have specific policies attached.. ;-))

I mean, you could do it without them.. you could put a raisefault in the preflow with a compound condition on it where you call out all the resource paths, but I think that it's less obvious for someone else looking at the proxy why one path throws a 404 and another doesn't. Also more likely to get hit by typo fragility when you have to make a change. ¯\_(ツ)_/¯

[DChiesa]

yes, and it looks like this in the config for the Proxy Endpoint:

<ProxyEndpoint name='whatever-you-like'>
  <HTTPProxyConnection>
    <BasePath>/api/v1</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>

  <FaultRules>...</FaultRules>

  <PreFlow name='PreFlow'>
   ...
  </PreFlow>
  <PostFlow name='PostFlow'>
   ...
  </PostFlow>

  <Flows>
    
    <Flow name='Flow 1 - products'>
      <Request/>
      <Response/>
      <Condition>(proxy.pathsuffix MatchesPath "/products") and (request.verb = "GET")</Condition>
    </Flow>
    
    <Flow name='Flow 2 - users'>
      <Request/>
      <Response/>
      <Condition>(proxy.pathsuffix MatchesPath "/users") and (request.verb = "GET")</Condition>
    </Flow>


    <Flow name='unknown request'>
      <Request>
        <Step><Name>RF-UnknownRequest</Name></Step>
      </Request>
      <Response/>
    </Flow>

  </Flows>

  <RouteRule name='InvokeRouteRule'>
    <TargetEndpoint>my-target</TargetEndpoint>
  </RouteRule>

</ProxyEndpoint>