miruky

Posted on Sep 7

Build a Lambda-Free Mock REST API with Amazon API Gateway

#aws #apigateway #restapi #tutorial

Introduction

Hi, I'm miruky.

Amazon API Gateway can return a response without calling Lambda, an HTTP server, or another AWS service. A REST API mock integration handles the request inside API Gateway and uses mapping templates to choose the integration status and shape the response body.

This Console run creates GET /status, returns a fixed JSON document, verifies it with API Gateway's method test, and deploys one Regional stage. The endpoint is intentionally unauthenticated for a short-lived validation and exposes no account data.

Only API Gateway receives requests in this exercise; there is no backend compute charge. REST API calls and data transfer can still be billed, so check the current pricing page linked below.

1. Create a Regional REST API

This validation uses the AWS interface in English and United States (N. Virginia). The API and its deployment remain in us-east-1.

The header confirms United States (N. Virginia) while the API Gateway Console is in English. This fixes the Region for the API and its deployment.

Use Amazon API Gateway's REST API exact-name search for miruky-rmursrxqoonhsurb. Confirm that no exact match exists before creation.

The exact filter for miruky-rmursrxqoonhsurb returns no API. That empty result establishes the resource boundary before creation.

Choose Build, select New API, and enter miruky-rmursrxqoonhsurb. Use the Regional endpoint type. For the current security controls, select SecurityPolicy_TLS13_1_3_2025_09 (recommended), choose Strict (recommended) endpoint access mode, and select Dualstack before creating the API. Do not import an example definition.

The form visibly pairs miruky-rmursrxqoonhsurb with Regional, SecurityPolicy_TLS13_1_3_2025_09 (recommended), Strict (recommended), and Dualstack. No example API or description is imported.

A Regional endpoint keeps the validation in the selected Region. The selected security policy requires TLS 1.3, while Strict mode validates that the request uses the expected API Gateway endpoint type and server name. This short validation targets a modern browser; a real client inventory should be checked before choosing a TLS-1.3-only policy. No API key, authorizer, cache, logging destination, custom domain, or client certificate is added.

2. Add GET /status with a mock integration

Create a child resource at /status beneath the root resource.

The resource tree shows /status directly beneath /. No other child resource is present.

For /status, create a GET method with the Mock integration type. After creation, use Method request to confirm that authorization is NONE and API key required is False for this synthetic validation endpoint.

The method settings combine GET, Mock integration, NONE, and API key required disabled. No backend endpoint or integration credential is configured.

The mock integration still needs an integration request payload. Open Integration request, choose Edit, expand Mapping templates, and replace the empty application/json template with:

{
  "statusCode": 200
}

That value selects the 200 integration response. It is not the body returned to the client.

The request template contains {"statusCode": 200} for application/json. This value selects the success integration response.

Before adding a response template, open the method's Test tab and run GET /status once. The request template selects status 200, but the response has no JSON body yet.

The first method test shows status 200 and No data under Response body. This failure state separates request-side status selection from response-side body shaping.

Return to Integration response, edit the default 200 response, expand Mapping templates, and replace the empty application/json template with:

{
  "status": "available",
  "source": "api-gateway-mock"
}

The method's default success response already defines the client-facing HTTP code. This response template supplies the client-facing body.

The response template contains available and api-gateway-mock under the default 200 response. These are the only body values returned to the caller.

3. Test the method inside API Gateway

Use the method's Test tab again and run GET /status without query strings, headers, or a request body.

The method test shows 200, available, and api-gateway-mock. Its result contains no external integration endpoint or backend identifier.

The corrected result proves that API Gateway completed both mapping steps. There is no Lambda request ID, integration endpoint, or function log because no external backend was invoked.

In this controlled setup, the 200 response with an empty body isolates the missing integration-response template: the request-side status selection already worked. After adding the response template, any remaining mismatch should be checked against both mapping templates and the default method response instead of being assigned to one layer from the status alone.

4. Deploy and call the Regional stage

Choose Deploy API, select New stage, and enter miruky-urphwqorrgsymmwp, then deploy the current API snapshot. Do not add a deployment description.

The deployment dialog shows miruky-urphwqorrgsymmwp as the new stage. After deployment, the stage keeps its default settings; this run does not provision an API cache, log destination, canary, or stage variable.

A deployment is a snapshot of the REST API, and the stage is the named reference clients call. Later changes to the resource, method, integration, or templates require another deployment before the stage serves them.

Expand the deployed-stage resource tree down to /status and its GET method. Keep the invoke URL private and make a client request with /status appended. The response should contain only this JSON:

{
  "status": "available",
  "source": "api-gateway-mock"
}

The stage tree shows miruky-urphwqorrgsymmwp, /status, and GET. A separate live request to that deployed method returned HTTP 200 with the same available and api-gateway-mock values. The invoke URL and service-generated API ID are excluded from the retained image and article.

Do not publish the invoke URL or address bar: the hostname contains the service-generated API ID. The body is sufficient evidence because both values were fixed before deployment and contain no account-specific data.

Wrap-up

The Regional REST API now has one resource, one GET method, and one mock integration. The initial test isolated an empty response, the response template supplied the missing body, and the corrected method served the same two-field document from the deployed stage without Lambda or another backend.

Mock integrations fit contract demonstrations, temporary front-end development, and fixed health-style responses. They are not intended for large templates, and an internet-facing production API still needs deliberate authorization, throttling, observability, and abuse controls.

Thanks for reading this far.

See you in the next one.

Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.

DEV Community