[Bug?]: Catch-all API route catches everything

[rvlzzr]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

When a catch-all route is an api route, it catches everything, overriding other routes.

Expected behavior 🤔

A catch-all api route should behave the same as a normal catch-all route, acting as a fallback.

Steps to reproduce 🕹

Start with the basic example, and note that you are able to access the index and about pages. Replace the contents of [...404].tsx with something like the following and note that everything returns 404 now, you are no longer able to access index or about.

export function GET() {
return new Response("404 File Not Found", {
status: 404,
headers: {
"Content-Type": "text/plain; charset=utf-8",
},
});
}

Context 🔦

This makes it difficult to use a non-html catch-all/404 page.

Your environment 🌎

No response

[ryansolid]

Hmm.. that's hard or atleast with our router agnostic approach. API check happens before we hit framework routing. We've talked about pulling them into a separate router too. One will have to run before the other and typically we leave the final catch-all to the framework. Are you suggesting that HTML routes should take precedence over API routes?

That is actually a little tricky to do because we aren't doing the routing until we are already rendering in the framework. We might not even have a router, as router is optional. Or the filesystem routes might be combined with other non-filebased routes. We can never assume to know all the framework routes at build time or before rendering.

I'm open to suggestions that don't compromise this, but I'd recommend using a different path system for API routes especially if catch-alls are involved.

[jzohdi]

@ryansolid similar to how there is a "scoring" associated with api routes (certain user defined api routes take precedence over others even if more than one match), what about the combination of page routes and api routes behaving in a similar way?

matchApiRoute could code be added that this will return early if page route is found that has a better "score" than the best api route's "score"?

[ryansolid]

I guess its a bit weird since API routes can't move or be modified. But it's completely possible for page routes not to be inserted in the same depth as their API routes so it would be comparing different things. Even if we have those page routes defined in the file system we don't know that is where they will end up. I'm not sure we can combine them in this way consistently. Again this might be just trying for too much flexibility but the APIs allow it. I've taken a stance to this point that anything we know from FileRoutes ahead of rendering should never be assumed to be the final routes (even the path).

[jzohdi]

I see, thank you for your feedback!

[ryansolid]

Yeah we will be changing the API soon to address this. But as it is currently it is by design. If you have opinions please join the discussion here: #1279