Serverless API with Lambda and API Gateway

Prerequisites: completion of Lambda Fundamentals; AWS SAM CLI installed (sam --version).

Version note: verified against docs.aws.amazon.com/apigateway (http-api-vs-rest) and docs.aws.amazon.com/serverless-application-model, July 2026. API Gateway's current official guidance is to default to the HTTP API type (API Gateway v2) for new Lambda-backed APIs unless you need a REST-API-only feature — API keys with per-client usage plans, VTL request/response transformation, built-in caching, AWS WAF integration, or private VPC endpoints. This project builds an HTTP API accordingly. SAM CLI ships frequently; run sam --version and compare against the SAM CLI GitHub releases page before assuming any flag below is unchanged.

API Gateway offers two distinct products for putting an HTTP front door on Lambda: the older REST API (API Gateway v1) and the newer HTTP API (API Gateway v2). They overlap heavily in the basic case — both do Lambda proxy integration, both give you a public HTTPS endpoint — but HTTP APIs are lower latency, meaningfully cheaper (roughly 70% cheaper per request at the same volume), and simpler to configure for the common case, while REST APIs carry extra features (API keys with usage plans, VTL transformation templates, built-in response caching, WAF integration, private endpoints) that most new projects don't need on day one.

AWS's own current documentation states the decision plainly: choose REST APIs only if you specifically need one of those extra features; otherwise, HTTP APIs are the default for new work. This project builds a small multi-route API on HTTP API, deployed declaratively via AWS SAM so the whole stack — routes, functions, permissions — lives in one version-controlled template instead of a sequence of CLI commands you'd have to remember and re-run by hand.