3 ms·
(Author of the spec here) The protocol could just as easily go over a WebSocket as HTTP (you'd have to change authentication mechanism, but that would be trivi
by nmjenkins 13y ago
(Author of the spec here)
The protocol could just as easily go over a WebSocket as HTTP (you'd have to change authentication mechanism, but that would be trivial). The only reason we don't do that at the moment is:
1. Browser support (we support back to IE8, unfortunately)
2. Lack of GZIP compression (particularly of responses from the server); this was being worked on last time I looked, but I haven't checked recently to see if it's been implemented yet. This is crucial for saving bandwidth.
That would get rid of your HTTP overhead; I will put some mention of that in the spec (I think HTTP support should be required, and WebSocket support optional).
As for JSON vs. binary:
* There are libraries to use JSON everywhere – binary protocols would require everyone to implement another parser, adding extra difficulty for adoption and a surefire source of bugs.
* JSON is readable over the wire, binary is not. Trust me, in the real world, this is a huge advantage for debugging all sorts of things.
* JSON can be used trivially in a web app. Apparently this World Wide Web thing might catch on.
* The parsing overhead of JSON is not too large; yes it's longer than a binary protocol, but it hasn't been a bottleneck for us, even on mobile.