Route Handlers allow you to create custom request handlers for a given route using the Web Request and Response APIs.
The HTTP methods supported are: GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS.
request (optional) and context(optional) carrying params are props received.
Imagine you need to build a simple webhook endpoint at /api/stripe-webhook that only accepts POST requests and returns a JSON success message. How would you set up the folder structure and write the route.js file to handle this?
You've written a GET handler in app/api/time/route.js to return the current server time, but users are complaining that it always returns the exact same time. What's causing this caching behavior, and how would you fix it so it returns the fresh time on every request?
We have a route.js handler that fetches data from an external database. We want to secure this endpoint so only authenticated users can access it. How would you read the session cookie or authorization header inside the route handler, and how would you handle unauthorized requests?
You are migrating an old Express.js API endpoint to a Next.js Route Handler. The original code relies heavily on Express middleware for parsing request bodies and setting custom headers. How do you replicate this middleware-like behavior or handle request parsing using the standard Request and Response objects in route.js?
We are building a high-throughput analytics endpoint in Next.js that receives thousands of write requests per second. How would you design the route.js handler to handle this load? Would you use the Edge runtime or Node.js runtime, and how would you handle connection pooling or rate limiting at this layer?
We need to stream a large AI-generated response (like OpenAI's GPT) back to the client in real-time. How would you implement a streaming response using route.js and ReadableStream, and what are the deployment considerations on platforms like Vercel or AWS Amplify?
Our organization is migrating a massive legacy monolith to a Next.js monorepo. Some teams want to build all new microservices directly inside Next.js using route.js, while others want to keep them separate. What architectural criteria would you use to decide when an API should live inside Next.js Route Handlers versus a dedicated backend service?
We have a multi-tenant SaaS platform where each tenant needs custom rate-limiting, CORS configurations, and authentication strategies applied to their API routes. How would you architect a reusable, maintainable middleware and routing layer around Next.js route.js handlers to avoid code duplication across dozens of endpoints?