3 ms·
We can probably blame misguided corporate IT policies for starting this trend, by blocking most of the outgoing ports and migrating many newer protocols to use
by unscaled 9y ago
We can probably blame misguided corporate IT policies for starting this trend, by blocking most of the outgoing ports and migrating many newer protocols to use TLS over port 443 (although it doesn't really have to be HTTP to bypass corporate firewalls).
This is still the most often cited reason, but I don't think it's a good one anymore (as said before, nothing prevents you from using TLS).
If you have a stateless protocol is dealing with autonomous request, HTTP is quite frankly the best general-purpose transport layer for you. The only other well-supported transport layers are the message-based UDP and the stream-based TCP, TLS (which offers encryption), SSH (which offers encryption and multiplexing).
If you've got a stateless request-based protocol, you want a message-response based transport, but UDP doesn't quite offer the same abstraction and lacks reliability guarantees and large message support. With a stream-based protocol on the other hand, you're bound to redo an ad-hoc, informally-specified, bug-ridden, slow implementation of half of HTTP[1].
Yeah, you probably don't need all of the features of HTTP for your protocol, but being able to use existing HTTP infrastructure solutions (such as proxies, load balancers, caches, testing tools, endpoint monitoring tools) is a great boon that you would never get with your own homegrown protocol.
[1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
- shmerl 9y agoHow would you implement something like push in HTTP for example? I remember, that XMPP had to come up with some hacks (BOSH[1]) to do it over HTTP. 1. https://en.wikipedia.org/wiki/BOSH_(protocol) https://en.wikipedia.org/wiki/BOSH_(protocol)
- jkarneges 9y agoStreaming (server trickles out a response that never ends) or long-polling (server intentionally waits before sending a full response) work very well for pushing data. BOSH uses long-polling, and as someone from the XMPP community I'll admit it's a bit of a hack around HTTP, mainly because it's stateful. However, it's entirely possible to have RESTful/stateless long-polling, for example in Dropbox's API: https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder-longpoll https://www.dropbox.com/developers/documentation/http/docume...
- shmerl 9y agoBy the way, can't WebSockets be used to solve this? It would still use HTTP for initial connection, but essentially can work without relying on streaming and polling hacks. And it's not really limited to usage in browsers.
- jkarneges 9y agoYup, WebSockets could certainly be used for push. I think the choice of HTTP vs WebSockets comes down to architecture style. WebSockets are optimized for bidirectional communication with a specific remote server. In other words, something about the service makes it better if client I/O is sticky, maybe due to an in-memory session. HTTP can make more sense in a stateless architecture, where GETs and POSTs could potentially go to different servers in the cluster. Of course, one could use WebSockets statelessly too (have no messages depend on past messages for context).