{"id":3493,"date":"2021-09-03T13:59:00","date_gmt":"2021-09-03T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3493"},"modified":"2024-02-02T11:59:58","modified_gmt":"2024-02-02T10:59:58","slug":"how-to-integrate-legacy-api-with-aws-api-gateway-proxy","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/how-to-integrate-legacy-api-with-aws-api-gateway-proxy\/","title":{"rendered":"How to Integrate legacy API with AWS API Gateway proxy"},"content":{"rendered":"\n
The emergence of modern web and mobile applications, based on microservices exposing HTTP APIs, has highlighted the need to effectively integrate, deploy, decommission, throttle, and securing a plethora of heterogeneous web APIs. This is mostly due to the inherent inhomogeneity of backend resources allowed and encouraged by the microservice pattern: each microservice composing a complex application may be developed and deployed in a unique way (programming language, deployment platform, etc) and some of them may even SaaS APIs, completely outside the direct control of the company developing the application as a whole.
<\/p>\n\n\n\n
Several companies and open source initiatives have developed API gateway<\/strong> solutions in order to meet the above requirements and expose a coherent API format for all the microservices composing the application.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n The AWS service that takes on this customer necessity is the AWS API Gateway, whose integrations with existing AWS and third-party services are described in the image above. Basically, this service acts as proxying (with the ability to modify and enrich the incoming requests), caching, load balancer, and general security layer for all the APIs.<\/p>\n\n\n\n Differently from many other solutions, AWS is fully managed and serverless, meaning that you won\u2019t need to worry about maintenance and scaling. AWS will do that for you and you\u2019ll pay a flat per request rate (for the REST APIs ~1.5$ per million requests).<\/p>\n\n\n\n Let\u2019s now delve into the main topic: why and how to use this service for integrating legacy APIs, but first a quick recap on AWS ApiGateway integrations.<\/p>\n\n\n\n <\/p>\n\n\n\n In the context of API Gateway, an API integration is the type of action performed by the gateway in order to respond to a given API request. The integration is invoked after the validation and authorization of the request (if configured\/needed). AWS API Gateway (API GW from here on) supports several types of API integrations:<\/p>\n\n\n\n A very common real-world API gateway use case, in which many of the previously described integrations are actually used, is the migration of a legacy application from an existing monolithic infrastructure to a modern microservice-based modularized application. In this use case, you\u2019ll typically have many API still hosted on the monolithic infrastructure and other APIs already migrated to AWS Lambda (with the AWS_PROXY integration) and\/or AWS ECS (Fargate) behind a load balancer.<\/p>\n\n\n\n API gateway will expose a single endpoint that can be mapped to a Fully Qualified Domain Name (FQDN) of your choice using the Custom Domain API Gateway functionality.<\/p>\n\n\n\n Proxying an existing API<\/strong><\/p>\n\n\n\n Let\u2019s now focus on the integration with the legacy monolithic part of the application being migrated and let\u2019s suppose, for sake of simplicity, the existing APIs to be publicly reachable, even if with some additional effort existing privately exposed APIs both on-prem and on AWS can also be proxied (https:\/\/docs.aws.amazon.com\/apigateway\/latest\/developerguide\/http-api-develop-integrations-private.html<\/a>). In the example provided here we\u2019ll use the Ireland (eu-west-1) AWS Region.<\/p>\n\n\n\n Let\u2019s start by creating a new API in the AWS API GW web console: open your AWS Account, go to the API Gateway service (https:\/\/eu-west-1.console.aws.amazon.com\/apigateway\/main\/apis?region=eu-west-1) and let\u2019s create a new API, we are presented with the following wizard:<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n The various types of API you can select here have different functionalities: Websocket APIs are used for full-duplex real-time applications, definitely not our case, while HTTP and REST APIs are both legitimate choices. HTTP APIs however implements just a subset of the features available with REST APIs, for example, Cognito Authentication, Iam Authentication, generic AWS service integrations, and velocity template requests transformations are not implemented. <\/p>\n\n\n\n In this example, in order to be as generic as possible, we\u2019ll select REST Apis but keep in mind that HTTP APIs requests cost less than 30% of API REST requests, so they are often the most cost-effective choice.<\/p>\n\n\n\n So let\u2019s click Build on REST Apis, then choose New Api and set name and description.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n The endpoint type defines where the endpoints are located: an edge endpoint creates a fully managed CDN (Cloudfront distribution) to deploy the endpoints in all the AWS regions, thus closer to the customers. The downside is that several operations (e.g. Custom Domain associations, deployments) are slower, the pricing instead is the same. Here we choose Regional.<\/p>\n\n\n\n Click Create API to finalize the creation wizard. <\/p>\n\n\n\n <\/p>\n\n\n\n Once the resource is created you can see it in the left bar as \/{proxy+}. You can select it and in Resource Actions first create a Method of type ANY with the following settings:<\/p>\n\n\n\n<\/figure>\n\n\n\n
API Gateway integrations<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
Now is finally the time to integrate our legacy API. The simplest thing you can do is to set up a plain proxy using the HTTP_PROXY integration. In this example, HTTP_PROXY integration targets the mocked Petstore API deployed by AWS at http:\/\/petstore-demo-endpoint.execute-api.com<\/a>.<\/p>\n\n\n\n<\/figure>\n\n\n\n