3 ms·
> Setting up and tearing down an HTTP connection for every little operation you want to do is not free. "Doctor, it hurts when I do this." So don't do
by deathanatos 8y ago
> Setting up and tearing down an HTTP connection for every little operation you want to do is not free.
"Doctor, it hurts when I do this." So don't do that; many HTTP libraries come with connection pooling / persistence built in, so it's quite common to not even need to handle this yourself. Should we also stop using relational databases because setting up a connection takes time?
As for the rest of it, sure, you might have a queue, or some orchestration layer. Is that your consumer-facing API? Just b/c I push a message into some queue implementation does not mean I want to expose that implementation to my caller.
- jimbokun 8y agoHe has an entire section on "Post-REST: Persistent connections" which you seem to have missed. "As for the rest of it, sure, you might have a queue, or some orchestration layer. Is that your consumer-facing API? Just b/c I push a message into some queue implementation does not mean I want to expose that implementation to my caller." REST for external APIs, and queues for internal, more tightly coupled micro services seems like a good way to architect things.
- otabdeveloper1 8y ago> He has an entire section on "Post-REST: Persistent connections" which you seem to have missed. That section is really stupid. He goes on about HTTP/2 and QUIC while seemingly being ignorant of HTTP/1.1's existence. Keep-alive has existed for decades. Use it, it solves the problem definitively without adding any new ones. (People have yet to figure out what the point of HTTP/2 and QUIC was. Except for Google's not-invented-here syndrome, of course.)
- temporallobe 8y agoFor web applications that use "traditional" RESTful APIs with AJAX, most of the overhead is from setting up an AJAX call for every single call instead of using an "always-on" listener like websockets.