The best solution for create a proxy APIGee with multiple TargetEndpoints

[andrekings]

Hey guys! Who can help me understand the best solution for routes in APIGee?

I have an API Proxy, with some endpoints for the same backend.

I thought about creating this proxy, creating the endpoints in the TargetEndpoint, being called by what would pass through the Proxy Endpoint, for example:

My Basepath: /autoservice/v1
TargetServer: https://service-dev.digital.cp (here I created a Target Server for environments with the name TS-ServiceDigital.

My endpoints:
- {brand}/create
- {brand}/search
- {brand}/detail/{protocolId}

I need to pass {brand} and {protocolId} as variables, which will be called in the backend with these parameters being passed in the URI. For this I have already created an EV-ExtractVariables policy

I've already done this whole process, in APIGee here, I created each endpoint like this in a TargetEndpoint... However, when I run it I get this error:

{
"fault": {
"faultstring": "Unable to route the message to a Target Endpoint",
"detail": {
"errorcode": "messaging.runtime.RouteFailed"
}
}
}

I would like to better understand if this solution is viable in APIGee, or if there is a better one where I can create a single proxy to call these respective endpoints in the Backend Service.

Thanks in advance.

[dchiesa1]

Can you show your ProxyEndpoint configuration?

Do you have RouteRules in place?

I can generate the error you reported when I have a Conditional RouteRule, and no "fallback" RouteRule. Like this:

  <RouteRule name="BrokenRouteRule">
    <TargetEndpoint>target-1</TargetEndpoint>
    <Condition>proxy.pathsuffix = "/foobar"</Condition>
  </RouteRule>

  <!-- This is wrong. There is no "fallback" aka "no Condition" RouteRule. -->

</ProxyEndpoint>

This seems like a validation problem on the Apigee side. I'll file a bug. In the meantime, you can avoid that problem by adding a default RouteRule, a RouteRule with no condition on it. Or otherwise make sure that one of the RouteRule conditions evaluates to true. (BTW, Apigeelint will flag this as a warning.)

I would like to better understand if this solution is viable in APIGee, or if there is a better one where I can create a single proxy to call these respective endpoints in the Backend Service.

I don't understand exactly what you're intending, but ... It's absolutely valid to use Apigee to route requests to multiple different targets.

You have the option of pre-defining the TargetEndpoints in Apigee, or configuring Apigee to use a "dynamic target". In the former case you will have one TargetEndpoint for each different upstream system. And inside each of the TargetEndpoint definitions, you will have something like this:

<TargetEndpoint name="target-1">
 ...
  <HTTPTargetConnection>
    <SSLInfo>
      ...
    </SSLInfo>
    <URL>https://endpoint-of-target1.example.com</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

Let's suppose you have 3 distinct targets defined that way. Then inside your proxyendpoint you can have RouteRules which route to them, conditionally:

  <RouteRule name="rule-for-target1">
    <TargetEndpoint>target-1</TargetEndpoint>
    <Condition>proxy.pathsuffix Matches "/brand1"</Condition>
  </RouteRule>
  <RouteRule name="rule-for-target2">
    <TargetEndpoint>target-2</TargetEndpoint>
    <Condition>proxy.pathsuffix Matches "/something-else"</Condition>
  </RouteRule>
  <RouteRule name="rule-for-target3">
    <TargetEndpoint>target-3</TargetEndpoint>
    <Condition>request.header.brand = "brand3"</Condition>
  </RouteRule>
  ...and so on...

</ProxyEndpoint>

Note: the Conditions need not all test the same thing.

The alternative to specifying distinct TargetEndpoints, and RouteRules , is to use a dynamic target. In that case you might have a single target, but you can dynamically set the target.url variable, via an AssignMessage/AssignVariable or a JavaScript policy or similar. To use this approach, you must set the variable in the Target request flow. == attach the policy to the Target Request flow.

Which you choose, depends on which you think is more clear and maintainable for your purposes.