In Part 1, we learned that API Gateway acts as the helpful "waiter" standing between your users and your backend servers. But when you log into the AWS Console to create your first API, AWS asks you to choose a menu: Do you want an HTTP API or a REST API?
Both of them do the exact same core job (moving data between a client and a server), but they have very different price tags and features. Let's break down the difference in simple English and then build one in less than 5 minutes.
The Fine Dining vs. Fast Food Analogy
Think of a REST API like a high-end, fine-dining restaurant experience. You get a massive menu of features: valet parking, custom table settings, and a sommelier . In the AWS world, this means built-in API keys to sell access to your API, strict request validation (making sure users don't send garbage data), and integration with AWS WAF to block hackers . But just like fine dining, it is heavier and costs more.
Think of an HTTP API like a high-quality fast-food drive-thru. It is designed to be lean, incredibly fast, and very cheap . It strips away the heavy "fine dining" features you probably don't need for a simple app . If you just want to connect a mobile app to an AWS Lambda function as quickly and cheaply as possible, this is your choice.
The Showdown: HTTP API vs. REST API
Here is a simple cheat sheet to help you decide which API type fits your project :
| Feature |
HTTP API (The Fast Track) |
REST API (The Heavyweight) |
| Cost |
Up to 71% cheaper than REST. |
More expensive. |
| Speed |
Lower latency (faster responses). |
Slightly higher latency due to heavy features. |
| API Keys & Monetization |
❌ Not supported. |
✅ Yes, you can generate keys and throttle usage per client. |
| AWS WAF (Firewall) |
❌ Not supported. |
✅ Yes, built-in protection against web exploits. |
| Edge-Optimized Endpoints |
❌ Regional only. |
✅ Yes, routes traffic through AWS's global network. |
| Built-in Caching |
❌ Not supported. |
✅ Yes, caches responses to save backend compute time. |
| When to use it? |
Connecting a simple web/mobile app directly to a Lambda function or a database. |
Enterprise apps, public APIs you want to sell, or highly secure financial apps. |
Let's Build Your First HTTP API (In 5 Minutes)
Since HTTP APIs are the easiest and cheapest way to get started, let's build a simple one right now. We will assume you already have a basic "Hello World" AWS Lambda function ready to go.
Step 1: Create the API
Log into the AWS Management Console, search for API Gateway, and click Create API. Under "HTTP API," click the Build button.
Step 2: Add Your Integration
API Gateway will ask you what you want this API to talk to. Click Add integration. Select Lambda from the dropdown, and then choose your "Hello World" Lambda function. Give your API a name (like MyFirstFastAPI).
A "Route" is just the specific URL path a user visits to trigger your code.
Set the Method to GET (this means the user is just asking for data).
Set the Resource path to /hello.
Make sure it points to your Lambda function.
Stages are independently configurable environments that your API can be deployed to. You must deploy to a stage for API configuration changes to take effect, unless that stage is configured to autodeploy. By default, all HTTP APIs created through the console have a default stage named $default. All changes that you make to your API are autodeployed to that stage. You can add stages that represent environments such as development or production.
Step 4: Deploy and Test!
AWS HTTP APIs have a magical feature called Automatic Deployments . As soon as you hit "Create," AWS immediately pushes your API to the internet.
You will see an "Invoke URL" on your screen. Copy that URL, paste it into your browser, add /hello to the end, and hit enter. Boom! You just triggered a serverless backend from the public internet.
d-l9jomka06f.execute-api.us-east-1.amazonaws.com/hello
What's Next in the Series?
Now you know how to build a basic stateless API. But what if you are building a chat application, a live stock ticker, or a multiplayer game where the server needs to push updates to the user instantly? A standard HTTP API won't cut it.
In Part 3: WebSocket APIs — Building Real-Time Magic, we will dive into stateful connections, where the API keeps the connection open constantly for real-time two-way communication.
