Next.js Discord

Discord Forum

pattern for route handling by accept header?

Unanswered
~sh4m1l65 posted this in #help-forum
Open in Discord
using Next.js v15, app router, I've defined some routes with React FC's for viewing resource collections:
- /things
- /widgets
- /objects

Nice table views with filtering, etc.

Now, I want to add "download CSV" to some of those, and if possible I'd like to use the same route. I wonder if there's an existing pattern for doing this kind of thing with Next? I wonder if I need to replace page.js with route.js but really I want both, and "somehow" choose between them using the HTTP Accept header values.
Am I thinking wrongly for considering these two views of the same resource to appear at the same URL path?

6 Replies

in another life I used a web framework that had a notion of "forwarding" requests (server-side) as an alternative to "redirecting" (which I think implies there would be an additional URL path to get the additional representation of the resource). Is there anything like that in Next.js? I want if possible to avoid exposing a new resource path to a different view of the same resource.
(Sorry, I don't mean so much to compare Next.js to web frameworks in other spaces, more just to explain where my thinking lies to see if I can get some help adjusting how I think about Next as a hypertext resource server)
you could technically set the middleware up so that if it sees the header and the pathname, it returns the csv immediately. i wouldn't do this though, but again, i wouldn't do whatever you are doing (react page component or raw response depending only on the request header) either
one of the rules upon which nextjs is designed on is: for any given pathname, it is expected to be used either by humans or bots. not both at the same time. if it's intended for humans, page.js. if it's intended for bots (returning raw response, returning machine-readable response, etc.), route.js
using the same pathname for different resource types intended for both humans and bots is not something often practiced in nextjs