Help with example of requesting Route Handlers (route.js) in the newest canary releases

[conorhub]

The docs give lots of of examples of how to establish and create new handlers but I haven't quite got my head around the logic of requesting them.

Are they meant to be explicitly requested?

For example, if I create the following route.js at /app/api/testroute/route.js

import { NextRequest, NextResponse } from 'next/server'

export async function GET(NextRequest, { params }) {
    console.log('contents route params: ', params);
    console.log('contents request: ', NextRequest);
    return NextResponse.json({ hello: 'Next.js' })
}

And then in /app/page.jsx :

const testFetch = await fetch('/api/testroute', {
    method: 'GET',
});
console.log('testFetch: ', testFetch);

I get a TypeError of:

TypeError: Failed to parse URL from /api/testroute

Am I misunderstanding how to use route.js, have I discovered a bug, or do I likely have a configuration problem?
I've pulled the latest canary image (13.1.7, I believe)

[icyJoseph]

Are you trying to call the server from within the server? That's not gonna fly (with relative paths), not even in pages directory.

You need an absolute URL when invoking fetch, otherwise I think the only way to call the API route with relative paths is from the "outside" like, from the browser, or any other HTTP client.

If you are not convinced then change to:

const testFetch = await fetch('http://localhost:3000/api/testroute', {
    method: 'GET',
});
console.log('testFetch: ', testFetch);

What this should tell you is that you are making an unnecessary jump from the server, onto the internet (not quite on this case), and back to the server again. If you are within a server component, just fetch the data you need there.

The point with these API handlers is to provide data to your client, at runtime, or other "consumers", which may not always want to have HTML for example.

[conorhub]

This is a complete perspective change, thanks for the explanation. I ended up wandering down this area as I've been trying to refresh an access token by setInterval every 10 minutes in a component.

Someone suggested I just check and refresh as needed when making calls to the API.
When I said that the API was third-party they mentioned wrapping those API calls in nextjs API .... which led me to here.

I believed I could reference an internal API on the same server.

All I really want to do is, before a REST request to an external API, check cookies for the existence of an access_token and do the usual (get a new one if there's a refresh token and set new cookies for both) etc. This needs to work both server and client side.

[icyJoseph]

Right, the thing is that the framework might be able to do something about it, for example, Nuxt does have something like it:

• https://nuxt.com/docs/guide/concepts/server-engine#direct-api-calls

I think for your use case, you could make a function around fetch, and pass cookies onto it.

In server components and these API routes (within appDir), you have access to the cookies function. So you could write a "function" that takes in cookies and whatever else you need to get the data and internally do the refresh if needed.

From the client you can point to your appDir API route, get the cookie there, and call this "function", then respond to the client with it. Assuming the cookie is HTTP only.

The server can just directly do that function as needed.

Please don't forget to mark as answered if you are satisfied :)

[conorhub]

I think for your use case, you could make a function around fetch, and pass cookies onto it.

I briefly looked into this but ran into a problem that's been a wall for a few options.

Namely, I don't seem to have a simple means to set cookies on the server, from the wraparound function:

• Next native cookies() only allows reading.
• Third-party solutions like nookies and next-cookie seem to rely on a getServerSideProps ctx, which I can't find a replacement for with /app in v13.
• Middleware can set cookies but I can't seem to intercept anything that's not a route in /app, which my wrapper function wouldn't be (unless I've missed something obvious)

So I'm at a loss on how to set a cookie in these contexts.

---

I should clarify that the app is mixed server-side and client components, like most nextjs projects. Per the recommendations in the docs, I'm trying to keep as much data fetching server-side as possible. Initially, all data is fetched server-side. Later, there's some occasional client-side fetching, per the demands of the user.

I'm, perhaps, slightly conflating the term client in your suggestion to take in cookies 'there'.