I am building a browser multiplayer game. For latency, I want to use WebRTC DataChannel to sync the game state. In my setup, one peer is always the server, which is always reachable (no NAT on server side, maybe on user side).
Most setups recommend using a websocket as the signaling channel. I saw some setups with manual copy-pase signaling, with one peer sending an offer to the other peer, the other peer sending an offer back.
Now, this sounds to me like a REST API - Browser does POST request with a SDP offer to the server, then receives SDP answer from server, both can establish connection. When the connection drops, they do that again. Client can always reach server, since that's on a public IP.
What is the disadvantage of doing it this way vs. establishing a websocket and keeping that open?
in a signaling session the SDP is not the only thing you are sending back and forth. So a short answer to why not to use REST API might be that when you trickle ICE candidates other than SDP there are so many messages going back and forth. I believe the SDP only will not have many problems with REST API but overall websocket is preferable basically even just because of websocket faster.