webMethods.io API Gateway: When To Use Routing Policies

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: