meta: add unified http api initiative

[jasnell]

HTTP APIs in Node.js have become a bit of a mess.

We have separate node:http, node:https, and node:http2 modules. We have separate fetch implementation. We have http3 support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc.

This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities.

@nodejs/quic @mcollina @nodejs/tsc

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[panva]

Sign me up.

[jonchurch]

Stoked to see this as a strategic initiative!

(I know this is early early days, but curious if anyone wants to share what's in their head or in discussions I've missed)

One clarifying question on "built around the web standard fetch model":

Should I read that as Node standardizing the future of request handlers on Request/Response primitives? Or am I looking at the wrong layer here and the end goal is an abstraction layer sitting below Fetch/IncomingMessage, speaking historic protocols as well as future ones? Or is it both: that abstraction layer underneath, with Request/Response handlers standardized on top of it?

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

For context on why I'm asking: I was expecting a unified HTTP API to address the shortcomings the Fetch spec has for modeling jobs that servers need to do. I see the Fetch spec serving browsers as its main constituents, and the tension that can create for servers wanting to model all the jobs they must do via Fetch primitives. So that phrase surprised me, and I'm mostly trying to align my mental model with what layer this new API would occupy relative to the existing stuff. Not opposed to any direction here, just want to clear the fog in my understanding of what problems are on the table.

In the spirit of intellectual honesty, my initial (mistaken) read

I often fall into the trap of categorizing Fetch as a protocol. I know it's not, but my brain often forgets that. I work on Express after all, where we have extended and intertwined with node:http to the point that Fetch looks like a different protocol to me, despite being a different API over the same protocols.

So my initial reaction was that a unified HTTP API would sit above Fetch/IncomingMessage and translate between them at the protocol level. But an implementation competing for the layer Fetch occupies sounds like the xkcd "14 competing standards becomes 15" trap, so I'm assuming that's not on the table hehe

You can see some more of my raw thoughts in this express thread from before I posted this question

[bjohansebas]

By the way, as far as I know, there are things that probably will never make it into the Fetch standard, but those things that don't belong in the Fetch spec could still be added as a standard variation within the WinterTC group. That way, both frameworks and runtimes can have a minimal API that runtimes are expected to support.

[jasnell]

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

The answer is likely some mixture of both.