Mule4 Proxy API

Introduction

If we want to hide our back-end API's complexity from the client or don't want our client to update their API configurations frequently due to our API endpoint changes, this blog will give you an idea about design proxy API.

Requirements

• Multiple APIs are deployed in different hosts and those are consuming by a client, and we want a single endpoint to handle those multiple calls for different APIs.

Proxy API Design

As per this design, client is not going to configure multiple backend API configurations in their side. They need to configure a single endpoint (i.e the proxy api endpoint). They need to pass all the backend API required informations in BODY section of proxy API while calling. On behalf of client, proxy API will call the required API and respond to client. The response could be valid or invalid, proxy API will pass the same to client.

1st Layer of Validation: CI/CS

As per basic Mulesoft standard, proxy API will enabled to default Client Id enforcement policy.

2nd Layer of Validation: Schema Validation

 The second layer of validation would be payload validation. The RAML schema validation will make sure about the mandatory payload validation. For example, 

1. whitelisted host (defined as mandatory enum).
2. Method (Rest HTTP methods are defined as mandatory enum) of backend endpoint.
3. Endpoint (backend endpoint details).
4. Forwarder-content-type (The content-type expecting by the backend API). Which is not a mandatory for schema validation, as some backend endpoints may not required that.
5. Body (The actual payload required by the backend API). Which is also optional. It would depend on the backend endpoint. We define the body type as "any" in RAML schema validation as the body type could be anything (like json, string, urlEncoded, etc.)

Sample RAML Schema (in Proxy API)

WhiteList the Backend API Hosts

In this design, proxy api will not save any client or back-end API details apart from host and port. That will create one layer of security. It means Proxy API will WHITELIST those backend API (by storing only the host and port in properties file), So that those stored host can only reachable via proxy api, nothing else.

Headers

The Security headers like Basic Authentication, Bearer Token, JWT, SSO, Client Id, Client Secret all can be pass through this proxy API. We have to send them in the header section and proxy API will pass them to the backend. Because, as those are sensitive data and any design standard does not encourage headers values to be replaced with body/payload.

Sample Request Message

POST /api/callBackend HTTP/1.1

Host: localhost:8082

Authorization: Basic YW5rdXI6Ymh1eWFu

client_id: test

client_secret: test

Content-Type: application/json

Content-Length: 845

{

    "host": "backend01",

    "method": "POST",

    "endpoint": "/api/createEmployee",

    "forwarder-content-type": "application/json",

    "body": {

        "firstName": "Ankur",

        "middleName": "Jyoti",

        "lastName": "Bhuyan",

        "email": "[email protected]",

        "gender": "Male",

        "phone": 9590951212,

        "currentAddress": {

            "isCurrentAddress": true,

            "street": "Elcetronic City",

            "city": "Bangalore",

            "district": "Bangalore",

            "pin": 56860,

            "country": "India"

        },

        "permanentAddress": {

            "isCurrentAddress": false,

            "street": "3 Rue Renee Aspe",

            "city": "Toulouse",

            "district": "Occitanie",

            "pin": 31000,

            "country": "France"

        }

    }

}

Proof Of Concept

To proof this proxy API design I prepared a POC. I developed this poc by configuring them using Mule4 domain project. Here is an overview.

Kindly find all the poc code here. And also find the postman script to test the endpoints,  kindly find here.

Author's Comments

• This design will best for those who has frequent changes in backend APIs.
• This design will best for those who has complex configuration in backend APIs.
• If we want to reduce the number of deployment cycles of our client API for new changes in back-end API(deployed in the same host/server), this design would be helpful.
•  This proxy api design will help to reduce the development and deployment hours and also developer's efforts.
• This design is proven only when we have body type of application/json, application/xml, text/plain, application/x-www-form-urlencoded. Not for multipart/form-data (file upload). But, I hope that also could be possible with this design.