I've been struggling with this, thanks for this one. I think I am experiencing the same right now.

What's the use case for making an accept: application/json request to a page? The code is there for historical reasons, but now that I think about it it's a bit of a strange thing to have. You can't (for example) request JSON from a +layout.server.js, so why load in +page.server.js should get this treatment eludes me. My inclination is to remove it.

At the very least the current behaviour would conflict with #5896.

I'm only using load in+page.server.js because it's now the only way to support the URLs that I need to. I'd prefer to be able to use the endpoint + page combination as before. I'm not "requesting a page", I'm making an http request to a route and just as the http method and path indicates what resource is being requested, so to does the accept header. Other headers might also factor into what the response is (host, authentication, cookies etc...). They are all part of the negotiation of "what should the response be to that request".

I don't expect the router to decide which headers it believes in. I need to be able to decide what routes and methods my app responds to and how. If a router isn't capable of supporting that then IMO it isn't really a true router anymore.

I guess what I'm after is the ability to use the router at the lowest level. I think all the other stuff should be extras built on top of that, but should be extras, not replacements. It should still be possible to have a plain burger without the magical, erm, sprinkles on top.

I appreciate some people will love all the extra form handling stuff, but I'd prefer to use ye-olde GET and POST directly myself if I want to.

I'm probably mixing up a few requests, but they are all inter-related (the server endpoint co-existence and the form actions).

RIght, but that's all covered by #5896, no?

What's the use case for making an accept: application/json request to a page?

@Rich-Harris You don't need two endpoint files for the same thing, my use case (posted this in the wrong issue before):

• I have bigger content properties but send only smaller, requested chunks via REST
• With the initial pageload the user gets the first part w/o a ded. api request
• Then, within the client the user can request further parts without the need to reload the page. Both use the exact same API and DB call

With the new routing, I need now two files that do the same.

My inclination is to remove it.

This broke my app. No chance to get this feature back?

@Rich-Harris any reason not to let +page.server.ts handle pure json requests, again?

Once #5896 is implemented, you can do something like this:

// src/routes/foo/+page.server.ts
export async function load({ fetch }) {
  const response = await fetch('/foo?chunk=0', { accept: 'application/json' });
  return response.json();
}

// src/routes/foo/+server.ts
export async function GET({ request }) {
  return getChunkFromDB(request);
}

No duplication that way

True! This is what I do as a work-around now with +server.ts in a ded. API folder tree. If +page.server.ts handled pure json, I need one file only, +page.server.ts (1), not +server.ts (2) and have response types preserved without the need to declare types in (1) and redeclare them in (2) though.

Don't want to annoy you guys but I still don't see any reason not to let +page.server.ts handle pure json requests, again and why this was disabled.