Integration: Utilizing Reverse Proxy to Host API Requests on Your Domain

Last updated
Save as PDF

Overview

Evolving digital landscape and hosting services in client-specific domains

In today’s rapidly evolving digital landscape, businesses require robust and secure API integrations that seamlessly align with their operational needs and security standards.

By configuring API requests to route through your domain using an API reverse proxy, you create a streamlined, trustworthy, and efficient gateway for browser and email client interactions. This approach provides compelling advantages over the traditional method of relying on a vendor’s third-party domain.

Enhanced Security and Control: By keeping API traffic within the realm of your domain, you retain complete oversight, enabling superior data protection and the ability to implement custom security policies that align with your organization's specific requirements.
Improved Reliability: Dependency on third-party domains often means being at the mercy of their uptimes and response rates. By proxying API requests through your domain, you take ownership of your service's reliability and can ensure stable performance for a better user experience.
Branding Consistency: Your domain is a crucial element of your brand identity. By directing API traffic through your domain, you maintain a consistent brand experience, fostering trust and credibility with clients who recognize your domain as a mark of authenticity.
Cross-Origin Resource Sharing (CORS) Compliance: Utilizing your domain for API requests simplifies the complexities associated with CORS, reducing potential cross-domain issues, and streamlining the data exchange process for web applications.
Future Flexibility: As your business evolves, your API strategy should be able to do the same. Having APIs on your domain provides the agility needed to scale your services, and switch backend vendors without disrupting the client applications, or modifying the API contracts. Embrace the path that puts you in the driver's seat: Set up your API requests on your domain today, and unlock the full potential of a secure, reliable, and cohesive technology infrastructure tailored to your business needs.

API-Gateway as a Reverse Proxy

This guide is designed to help you create a reverse proxy to prevent web browsers and email clients from marking direct API calls to Personalization Cloud through recs.richrelevance.com, https://image.richrelevance.com, or recs.algorecs.com as cross-origin requests. Setting up a reverse proxy on the customer’s setup, you will be able to:

Configure your web browser to route all API requests to Personalization Cloud through your domain.

Note: For more details on managing direct API integrations with web browsers, refer to the API (Recommend) Client-Side Implementations.

Set up email recommendations and content so that when emails are opened and links are clicked, the resulting API requests are directed through your domain.

Note: For more details on Email Recommendation setup, please refer: Email Setup, Content in Email Guide, Recommend in Email Best Practices Overview.

The following sections outline how a reverse proxy solution can be set up using services provided by AWS Cloud. The API-Gateway Reverse proxy can be set up on any publically available API Gateway solutions. The services that will be referenced in the sections are the following.

API gateway: This service will be the core of the setup to proxy the client request to the Personalization cloud domain and render the content back to the client as if the response originated from a server hosted behind the client domain.
Route53 (DNS service): This service will be used to map the customer subdomain to the API gateway-generated random URL.
ACM SSL certificate (SSL certificate management solution): This service will be used to install an SSL certificate on the client-specific subdomain, as this will be the user-facing URL.

Note: Any API gateway solution in combination with DNS and certificate management service can be used to set up a reverse proxy solution at your setup.

Configuring Reverse Proxy

API Gateway Setup

Perform the following steps to set up API Gateway as a Reverse Proxy:

On the API Gateway console, create an HTTP API with an appropriate name (for example, we have set up ‘RR-Email-Images’ as a new API).
Leave the other options to default, click Next, and then click Create.

Select Routes under the Develop section to create a route for your ‘RR-Email-images’ API.

Select Integrations under the Develop section to integrate routes.
1. Select the appropriate route under Attach integrations to routes.
2. Select HTTP URI - ANY from the dropdown list.
3. Under Integration details for route, provide the URL (https://image.richrelevance.com/{proxy} OR https://recs.richrelevance.com/rrserver/api/rrPlatform/recsForPlacements/{proxy}).

Leave the other settings to default, and click Create.
Repeat steps (i) to (iv) to integrate more routes if created.

Creating a Custom Domain

As the next step, create a custom domain for end-user facing and SSL-offloading. Perform the following steps to create a custom domain for end-user facing.

Select Custom domain names in API Gateway service.
Under TLS, let it be TLS 1.2.
Under Endpoint configuration, select regional for Endpoint type.
Select the appropriate SSL certificate specific to the domain.
Click Create domain name.

Note: The custom domain created in the above image is https://rremailimages.algonomy.com

Under the newly created custom domain, select API mappings.
Click Configure API mappings and select the appropriate API and default stage.
Click Save.

Under the newly created custom domain’s configuration, make a note of the API Gateway domain name for DNS mappings.

DNS mapping

In your DNS service, perform the CName (Canonical Name) mapping of Client's custom domain and API Gateway domain name that was configured in the previous sections.

Sanity Test

This guide shows you how to set up a system that displays images and links from your emails on your own company’s domain. This way, when customers open emails you send using Algonomy’s Personalization Cloud's email solution, the images and links will appear seamlessly from your website.

Note: This method works for any Personalization Cloud service that provides APIs on our richrelevance or algorecs domains.

Email open requests before API reverse proxy was applied. You can see the request is directly making an HTTP call to https://image.richrelevance.com.

https://image.richrelevance.com/rrma...4&utm_term=RR1

The same email open request after the API Reverse Proxy was set up. You can see that the image is rendered from https://rremailimages.algonomy.com

API-Gateway Proxy Resource

A proxy resource is a special type of resource that acts as a catch-all for any path segments that don't directly map to a specific resource path defined in your API. It forwards incoming API requests to a backend service without any modification to the path.

In precise, it captures requests to any path that doesn't match a defined resource path in your API and Forwards the entire request path (including any sub-paths) to your integrated backend service, allowing us to handle a wide range of dynamic URLs without needing to define individual resources/paths.

Similar Approach and Their Trade-offs

1. Wildcard Routes: A proxy resource as implemented in AWS API Gateway is not a universally adopted feature in all open-source API gateways. Some open-source API gateways, like Kong and Tyk, allow defining wildcard routes using patterns like * or /:wildcard

2. Catch-All Endpoints: Certain open-source API gateways allow defining catch-all endpoints that capture any unmatched paths. NGINX can be configured as an API gateway using its proxy_pass directive to forward requests to backend services.

3. Ease of Use: Open-source API gateway solutions may offer flexibility and customization options like AWS API Gateway's proxy resource feature but may need further analysis & POC’s. Also, developers can write code to handle incoming requests and dynamically route them based on path segments, headers, or other criteria, but it requires more development effort compared to the pre-built functionality of a proxy resource in AWS API gateway.

Moreover, compared to an API gateway, other approaches may contribute to the complexities associated with managing individual paths and routes.