Route Handlers and Building APIs

Server Components and Server Actions cover most of what an App Router application needs to read and mutate data, but there remains a clear category of work they do not address: building HTTP endpoints that are consumed by something other than your own React UI. A mobile app, a third-party integration, a webhook from a payment provider, a public API for partners, or a script that polls for data all need a real URL that responds to HTTP methods with a structured response. Route Handlers are the App Router's answer to this need — a file named route.js that defines functions for HTTP methods like GET, POST, PUT, PATCH, and DELETE, turning a folder into an API endpoint.

It is worth being precise about when you reach for a Route Handler versus the alternatives, because beginners often build APIs out of habit when a Server Component or Server Action would be simpler. If your own React Server Component needs data, fetch it directly in the component — you do not need an internal API for that. If your own UI needs to mutate data on a user action, use a Server Action — you do not need a POST endpoint for that either. Route Handlers earn their place specifically when the consumer is not your rendering pipeline: external clients, machine-to-machine integrations, webhooks, and cases where you genuinely need to expose or receive HTTP with full control over status codes, headers, and response bodies. Understanding this boundary keeps you from reintroducing the very API-layer boilerplate that Server Components and Actions were designed to eliminate, while still giving you real HTTP endpoints exactly where they add value.

Analogy🏏Cricket

🏏 Think of it like cricket: Picture a Test match where, before the openers walk out, the curator has already prepared the pitch, the umpires are positioned, and the scoreboard is live — the players just play. Plain React is like arriving at an empty ground and being told to roll the pitch, set the field, and wire up the scoreboard yourself before a single ball is bowled. Just as the prepared ground lets the batsmen focus on batting rather than groundskeeping, Next.js prepares routing, rendering, and bundling so you focus on features rather than plumbing. Just as the live scoreboard shows runs the instant a shot is played, server rendering hands the browser finished HTML the instant the page loads. And just as every Test follows the same agreed laws so any team can play anywhere, the App Router's file conventions mean any developer can read the folder structure and instantly know the routes. This reveals why Next.js wins on large teams: shared conventions remove the guesswork that custom setups create.