NextJS API Routes

Pro Members Only

This lesson is available if you have an active subscription.

Alternatively, some member might be able to gift it to you.

If you already have a subscription, you can sign in.

NextJS API Routes

Subscription Required

You must have an active subscription to access this content.
If you already have a subscription, you can sign in.

An amazing feature of NextJS is its ability to create server APIs from within the same codebase that provides the frontend ui.

Core Concept

You can create an api in nextjs quite easily by exporting methods from a route handler module (route.ts). It integrates into the nextjs router and becomes available at a url by using the folder structure (same way as page.tsx).

An example api which supports GET is demonstrated below. It will become available at url /demo because of its filepath.

app/demo/route.ts
export async function GET() {
return Response.json({
message: "Hi Fam 🚀",
});
}

Don't Mix page and route

One thing to be aware of is that you cannot have a page and a route module in the same folder.

This is because a page is nothing more than an html response to browser GET request.

As an example the page.tsx file will become invalid if we have a route.ts file in the same folder.

app/demo/page.tsx
app/demo/route.ts
export default function Page() {
return (
<div>
Sample Page
</div>
);
}

Request Object

Just like you can use the standard Response api to generate a response, you can use the web standard Request api to read the body of incoming request. You accept the request as a parameter to the API function.

In the below example we use the .json method to parse the incoming request and then use a property from the parsed object (name) as a part of the response.

app/api/route.ts
export async function POST(request: Request) {
const json = await request.json();
return Response.json({
message: `Hello ${json.name}!`,
});
}

Methods

In addition to GET and POST, API routes within nextjs support other common http methods as well.

Complete list:

  • GET
  • POST - common to take a body payload
  • PUT - common to take a body payload
  • PATCH - common to take a body payload
  • DELETE
  • OPTIONS
  • HEAD - automatically supported if you provide a GET

Note that HEAD is nothing more than a GET, the only difference is that HEAD will only return the headers.

Various methods are demonstrated below.

app/api/route.ts
export async function POST(req: Request) {
const json = await req.json();
return Response.json({
method: "POST",
request: json,
});
}

export async function PUT(req: Request) {
const json = await req.json();
return Response.json({
method: "PUT",
request: json,
});
}

export async function PATCH(req: Request) {
const json = await req.json();
return Response.json({
method: "PATCH",
request: json,
});
}

export async function DELETE() {
return Response.json({
method: "DELETE",
});
}

export async function OPTIONS() {
return Response.json({
method: "OPTIONS",
});
}

export async function GET() {
return Response.json(
{
method: "GET",
},
{
headers: {
method: "GET",
},
}
);
}

Method Not Allowed

A question you should have at this point is, what will happen if you call an API with a HTTP method that is not exported by our route handler?

Answer: NextJS will automatically return an error response on your behalf HTTP 405 Method Not Allowed.

As an example the below API only works on GET and POST requests and will return a 405 for other methods like PUT.

app/api/route.ts
export async function GET() {
return Response.json({
method: "GET",
});
}

export async function POST(req: Request) {
const json = await req.json();
return Response.json({
method: "POST",
request: json,
});
}
javascript
typescript
react
playwright

Enjoy free content straight from your inbox 💌

No spam, unsubscribe at any time.

Transcript

00:00

An amazing feature of next JS is its ability to create server APIs from within the same code base that provides the frontend ui. You can create an a i in next JS quite easily by exporting methods from a route handler module. It's built on top of the next year's app router and just like a page do TSX file will service the frontend. You can create a router ts file anywhere within the app folder and it'll be exposed by next JS as an API route. So this API will exist on URL slash demo. HTT P works on top of http methods

00:33

and the most common method is get In order to handle HTT P get requests, we export a function called get from the route module API. Routes are built on top of modern web standards and a feature provided by the modern web is this class called Response. In order to return a text response, we create a new instance provided the text and return the response object from a get method. Now let's test this API by using an H TT P client. We send a get request to local host 3000 slash demo and no surprise we get the response containing the text.

01:09

Most APIs nowadays don't use text. The most common format is actually Jason and the response class provides a static method specifically for this purpose, conveniently called json. This method takes a Tao script object and it will serialize it to JS as a part of the response. So let's test out this updated API. We make the same get request and this time we get back a JSON payload. And additionally you can notice within the header that content type is set to application slash json. One thing to be aware of is that you cannot have a page and a route module in the same folder as an example.

01:43

We have a simple page under the demo URL and if you go ahead and make an H TT P request to slash demo, we get back the rendered page as HTMO. That is because when you visit A URL in the browser, it is nothing more than a get request. What this means is that if we create a route within the same folder and export a get method, this will actually shadow the existing page. As far as next JS is concerned, this page is now completely useless and we can verify this by making the same get request again. And this time we get the API response and the page is completely shadowed.

02:17

In fact, if you visit this URL within the browser, the API response is returned and that page never kicks into action. Just like you can use the standard response API to generate a response, you can use the web standard request API to read the body of the incoming request. The most common HGTP method used to read the body of an incoming request is HGTP post to handle post requests. Within our route, we export a function called post. The request will get passed into this method as a function parameter. The type of this request will be the standard

02:49

web API request. There are a number of things that we can do with this request object and a simple one is that we can use a method called Jason to pass the incoming request From Jason to a JavaScript object. Now let's use this past object as a part of our response. We expect the incoming request object to have a member called name. So we return a response that displays the name back to the user. Let's demonstrate this successful acceptance and passing of an incoming request. By making a sample API call, we will make a post request to the API providing adjacent payload

03:23

with a name property set to John Doe. When we make the call the API will pass the incoming request adjacent payload and then return the name property from the past object back as a part of its output. In addition to get and post API routes within next days support other common HGTP methods as well. We've already looked at how we can accept a body payload using a post method. Other methods that conventionally take a payload are put and patch and all that we have to do over here is just export methods called put. And similarly a method called patch.

03:57

Other HTV methods don't conventionally take a body. For example, we can add a delete method that is conventionally used to delete a resource. And similarly we can add an options method which is conventionally used for things like course. And then finally, we've already looked at the GET method, but here we are making one more modification. Within the response of the GET method, we are adding an additional header called method with the value set to get. This will help us demonstrate another HTV method that is actually supported directly from the get response. Now if you make a request using the HTP post method,

04:32

you can see that our post function was invoked and the response was returned similarly for put and for patch and the same for other HTP methods as well, which are delete options as well as get notice that in addition to looking at the payload to identify which method was invoked in this case get was invoked. We coded up our get to also return an additional header called method with the value set to get. This is to demonstrate another HTV method of an overlooked called head. We didn't actually export a method called Head,

05:05

but you can see that a request can still be made to this method. Exporting a GET method actually automatically adds support for the head method. The head method is nothing more than a request to get the difference between get and head is that with head only, the headers are returned, the body is completely ignored and we can see that the underlying request was indeed to a get method as indicated by the additional header that we added method get. A question you should have at this point is what will happen if you call an API with an SGTP method that is not exported by a route handler to demonstrate this.

05:40

We have a route handler that only exports the GET and the post methods. This means that we can make a request to get and we get back a successful response. And similarly, if you make a post, we get back a successful response. But what will happen if we make a put request, well next yes, will automatically return an error response. SGTP four or five method not allowed.