HTTP is really good at being a generic RPC protocol, what with proxy support and authentication and caching and content negotiation and automatic redirects and chunked streaming and etc. etc. ad infinitum. This, and not the fact that web browsers use it, is why people implement their service APIs in HTTP.
When you give a developer a websocket/WebRTC data channel/etc. and tell them to do RPC over it as a "lower-overhead alternative to HTTP", you inevitably get badly-greenspun (and almost never actually-lower-overhead) HTTP. Making HTTP itself lower-overhead is the best decision in the medium-term.
(In the long term, an HTTP-compatible RPC protocol that runs directly over SCTP+DTLS would be pretty cool, though.)
Comments
HTTP is really good at being a generic RPC protocol, what with proxy support and authentication and caching and content negotiation and automatic redirects and chunked streaming and etc. etc. ad infinitum. This, and not the fact that web browsers use it, is why people implement their service APIs in HTTP.
When you give a developer a websocket/WebRTC data channel/etc. and tell them to do RPC over it as a "lower-overhead alternative to HTTP", you inevitably get badly-greenspun (and almost never actually-lower-overhead) HTTP. Making HTTP itself lower-overhead is the best decision in the medium-term.
(In the long term, an HTTP-compatible RPC protocol that runs directly over SCTP+DTLS would be pretty cool, though.)