That's not how game networking works.

First, REST requests have significant per-request overhead. You'll want a custom protocol that discards all of the overhead you don't need.

Second, sending all the scene transforms as a “snapshot” is super inefficient, both because some objects don't move, and because some objects move more or less predictably, and thus can be simulated on the client and the server and come to (close to) the same result on both sides.

Thus, a typical networked game doesn't have the client “request” what should be seen, but instead has the client run a general game simulation, and have the server “push” corrections (inputs from other users, server-decided tie breaker outcomes, etc.)

There's tons of write-ups on this kind of structure, including older threads in this forum, but chances are, you need to take a step back and start over, assuming that all data lives in RAM (not database,) and you only send occasional updates from the server to the client (plus the “events” that really affect simulation, including the inputs from other players.)

“UDP streaming protocol” (although that will get you a lot of RTP type video streaming)

“UDP state replication” would work.

Read the code for the Quake games – it's open source, and fairly easy to read, assuming you know C.

Which technologies you use, depend entirely on what your game is.

If your game is turn-based and asynchronous, a simple REST system might be good enough. A game like chess is turn-based, but synchronous – time matters – and thus something slightly better is likely needed. If your game is a racing game, or a first person shooter, or an action-adventure, or a platformer, you probably need a streaming state replication approach, not request/response.

If your game HAS to be played in a browser, then you will need to use Websockets. You can “stream” over Websockets, but TCP head-of-line blocking when packets are dropped will cause lag spikes. There's nothing you can do about that.

If you have a mobile or native client, then UDP sockets are the way to go. On Windows, that's using the Winsock API. On MacOS and Linux and iOS, that's using the UNIX sockets API. On Android, you can choose between their “flavored” sockets (Java) or the underlying UNIX sockets API. Saying the sockets API is “old” is like saying that file I/O is “old” – it's a function, it's performed by the computer, it hasn't changed in forever.

That being said, for large scalability, you will want to use overlapped/asynchronous/evented I/O for your sockets on the server – but you're nowhere near the point where you need to worry about per-socket per-player overhead.

In addition to the Quake source, you can look for popular networking libraries for games, like ENet (C), Raknet (C++), or Lidgren (C#). Or run through the networking tutorials in the Unreal Engine youtube series, which will give you an idea of the higher-level concepts, and then you can map those to UDP sockets underneath.

Finally, influx, kafka, and pulsar, are systems to deal with streaming at the “seconds of latency” level, for bulk data. They are not suitable for a client/server networking setup for games, both because their latencies are way too high, and because their security models aren't suitable for the needs of most game networking setups. They can, however, be used on the back-end, for doing things like collecting metrics, or notifying “important” game events to central systems, or maybe even forwarding in-game text chat, at least if it needs to travel across server instances.

For internet enabled games played over a WAN, the specifics of endpoint connections generally don't matter.

The one case that might be interesting is if you connect through a mobile phone endpoint, AND if that mobile phone endpoint roams such that it gets assigned a new IP address. In that case, you need to either re-establish the session, or support some mechanism for session migration to a new IP on the server. This is, generally, a pretty rare case, though.