Postman’s API Gateway Testing: Kong and AWS APIGW
The most surprising thing about testing API Gateways with Postman is how often the gateway itself is the last thing you should suspect when things go wrong.
Let’s see it in action. Imagine we have a simple "hello world" API running on a backend service, and we’re exposing it through both Kong and AWS API Gateway.
First, the backend service. It’s a basic Node.js app listening on port 3000:
const http = require('http');
const server = http.createServer((req, res) => {
res.statusCode = 200;
res.setHeader('Content-Type', 'text/plain');
res.end('Hello, World!\n');
});
server.listen(3000, '127.0.0.1', () => {
console.log('Server running at http://127.0.0.1:3000/');
});
Now, let’s set up Kong. We’ll assume a basic Kong installation with default settings. We’ll create a Service pointing to our backend and a Route to expose it.
In Postman, we’ll first test the backend directly to ensure it’s up and running:
GET http://localhost:3000/
Expected response: Hello, World! with a 200 status.
Next, we’ll test Kong. Assuming Kong is running on localhost:8000 for HTTP traffic and we’ve configured a route like /kong/hello that maps to our backend service:
GET http://localhost:8000/kong/hello
If this works, you’ll again see Hello, World!.
Now, AWS API Gateway. This is a bit more involved, as it requires setting up a REST API, a resource (/hello), a method (GET), and integrating it with our backend. For simplicity, let’s assume we’re using a Lambda function that just returns "Hello, World!" and that Lambda is triggered by the API Gateway.
We’ll deploy this API, and get an invoke URL like https://abcdef123.execute-api.us-east-1.amazonaws.com/prod/hello. Our Postman test would be:
GET https://abcdef123.execute-api.us-east-1.amazonaws.com/prod/hello
Again, we expect Hello, World! with a 200 status.
The real power comes when you start adding complexity: authentication, rate limiting, transformations. Postman is your sandbox to rapidly iterate on these. You can build collections that mirror your gateway’s structure, testing each endpoint and each policy.
For example, let’s say we add Kong’s key-auth plugin to the /kong/hello route. We’d need to provision a consumer and a key.
Kong Admin API (for provisioning):
curl -X POST http://localhost:8001/consumers --data "username=testuser"
# Note the ID of the created consumer
curl -X POST http://localhost:8001/consumers/<consumer-id>/key-auth --data "key=mysecretkey"
Now, our Postman test for the authenticated endpoint:
GET http://localhost:8000/kong/hello
Authorization: Key mysecretkey
If you get a 401, you know the key auth failed. If you get a 403, the key is valid but not authorized for that route.
The mental model for API Gateway testing with Postman hinges on isolation and verification. You’re not just testing if the API responds; you’re testing if the gateway is correctly routing, authenticating, authorizing, transforming, and rate-limiting requests as intended, before they even hit your backend. Postman becomes your primary tool for orchestrating these tests, simulating various client behaviors and validating the gateway’s policy enforcement.
When you’re testing an API Gateway, especially one as feature-rich as Kong or AWS API Gateway, it’s crucial to understand that the response you get from the gateway isn’t just the backend’s response plus headers. It’s a composite, where the gateway’s plugins and configurations can alter the request before it reaches your service and the response after it leaves. For instance, a request-transformer plugin in Kong can add headers to your backend request that your backend service never sees, or it can rewrite the path entirely. Similarly, AWS API Gateway can map parameters, transform bodies, and even inject headers into the backend integration. Postman lets you craft requests that specifically probe these transformations by inspecting both the response body and headers, and by sending requests with unusual or malformed parameters that might trigger specific plugin logic.
The next step is often integrating these gateway tests into a CI/CD pipeline, turning your Postman collections into automated checks.