webMethods.io API Gateway: When To Use Routing Policies

Knowledge base
,
1

Introduction

This article explains about when to use what policy in routing.

Audience

It is assumed that readers of this article know how to setup policies on API Gateway.

Pre-requisite

Why do we need Routing Policy?

  • The policies in this stage enforce routing of requests to target APIs based on the rules.
  • We can define to route the requests and manage their respective redirections according to the initial request path.
  • We have to choose the sub policy wisely, as all the sub policies are selected in mutually exclusive manner for example, we cannot select Content based and context-based policy simultaneously.      

List of sub policies available in Routing

Content-based Routing:

  • Content-based routing protocol to route specific types of messages to specific endpoints.
  • We can route messages to different endpoints based on specific values that appear in the request message.
  • For example, we can use this policy, to determine payload and then route to endpoints for which the condition matches.  

Context-based Routing:

  • Context-based protocol to route specific types of messages to specific endpoints.
  • The requests are routed according to the context-based routing rules we create.
  • We can set different conditions on context-based routing policy on different criteria’s like who is the user, what is the routing method, what is the operation name, what is the Getaway API and many more.
  • This policy is quite useful in the scenarios when we want route the request without knowing what payload is sent from the client.

Dynamic Routing:

  • This policy enables API Gateway to support dynamic routing of virtual aliases based on policy configuration.
  • The configured policies are enforced on the request sent to an API and these requests are forwarded to the dynamic endpoint based on specific criteria that we specify.   

Load Balancer Routing:

  • An API that is hosted at two or more endpoints, we can use the load balancing option to distribute requests among the endpoints.
  •  The requests are routed based on the round-robin execution strategy.

Straight Through Routing:

  • When we select the Straight Through routing protocol, the API routes the requests directly to the native service endpoint we specify.

Custom HTTP Header:

  • We can use this policy to route requests based on the custom HTTP headers specified for the outgoing message to the native service.

Outbound Authentication – Transport:

  • When the native API is protected and expects the authentication credentials to be passed through transport headers, we can use this policy to provide the credentials that will be added to the request and sent to the native API.

Custom Extension:

  • When we want to route the transaction to some external endpoint using Messaging, AWS lambda, IS service or some external endpoint.

Use Case Summary:

              

686×662 9.47 KB
   

2

Examples of using these would be fantastic.

The “Content-based Routing” policy seems…very limited based upon the fields in the rule definition. Is this policy geared only to identify the calling application? If so, isn’t that redundant with the “Identify & Authorize Application” policy?

I’m trying to route to an end-point based upon the value of a field in the payload, regardless of the calling application. Based upon what I see, that does not seem to be possible – but hopefully I’m missing something not-so-obvious.

(Using on-prem API GW, not wM.io)

3

Rob, I think you have "content"and “context” mixed up.

The former is what you’re looking for with payload-based routing, whereas the latter is based on “metadata” variables (well beyond the identifiers available with the Identify & Authorize policy).

The use case example above doesn’t cover all the contextual variables that are supported. Else, if you’re already aware of all the supported contextual variables, then which additional ones do you think are missing and must be supported?

P.S - If I’m not following your requirement, can you elaborate further?

KM

4

Kasi – I think I am clear on the difference between content- and context-based. I am looking for content-based (we’re using context-based in another API). Given this sample payload:

{
  "abc" : "123x",
  "function" : "xyz",
  "foo" : "bar"
}

I want to define a rule to route to specific targets based upon the value of say, $.function. Not dynamic–the value isn’t to be part of the URL. For example:

if $.function == “xyz” route to endpoint https://abc.com/foo/bar
if $.function == “flippityfloop” route to endpoint https://southpark.com/marklar

Here is the properties pane of content-based routing in 10.5:

image
image611×810 24.8 KB

The documentation for this policy describes Payload Expression as “Specifies using the payload identifier to identify the client, extract the custom authentication credentials supplied in the request represented using the payload identifier, and verify the client’s identity.”

The documentation goes further to describe Expression Types and the JSONPath type: “Provide the Payload Expression that specifies the payload expression that the specified JSONPath expression type in the request has to be converted to. For example: $.name.id”

Those descriptions and the properties pane are exactly the same as those for “Identify and Authorize Application” used to extract a value that can then be matched with an application. As elaborated upon at webMethods.io API Gateway: Securing APIs using Payload Element

There, one defines how to extract the app ID value of interest from an arbitrary element in the payload. Then, assign values in the application config for the “Payload Identifier” identifier. Makes good sense there.

Content-based routing config does not seem to match the high-level description “You can route messages to different endpoints based on specific values that appear in the request message.”

What am I missing?

[Edit] I suspect what I’m missing is simply to use JSONPath filter operators although those are used to filter arrays. E.g. $.function == “xyz” as my example above. I’ll dig into that, but it would awesome if the docs and panel labels were a bit more clear…

[Edit2] Success! Using this expression did what I wanted. [?($.function==“xyz”)]

1 Like
5

Ah, you solved it already - this must be a forum post and not lost in the article comments.

KM