6 ms·
The problem isn't CURL, but HTTP. It's actually suprisingly complex and really needs to die. That'll never happen though.
by secondcoming 5y ago
The problem isn't CURL, but HTTP. It's actually suprisingly complex and really needs to die. That'll never happen though.
- Piskvorrr 5y agoJust as we managed to do that so well with SMTP and FTP ;)
- pjmlp 5y agoPlenty of applications use TCP and UDP, or even custom protocols on top of raw IP. Not everything needs to come through the browser.
- Piskvorrr 5y agoNot everything on top of HTTP comes through the browser, either ;)
- bombcar 5y agoMore and more APIs use HTTP as the transport for various reasons, but one of them is that HTTP has considered large number of edge cases and has been tested "in the fire" - rolling your own custom API with security and encryption is much more fraught with dangers.
- pjmlp 5y agoExcept HTTP 2.0/3.0 has very little to do with HTTP 1.0, and is more akin to use TCP/UDP directly anyway. It just happens to get a free pass over port 80.
- bombcar 5y agoAnd that's the other major reason - if your traffic LOOKS like web traffic, it will slip through firewalls and other middle-ware devices.
- secondcoming 5y agoBut I would bet that those only use the GET or POST functionality of HTTP, and that the real reason it's used is because it's easy to quickly get something up an running. It's a short-term gain, but quite inefficient in the long run. ZeroMQ is a perfectly valid replacement for HTTP in internal networks. There's no reason for everything to be human readable.
- secondcoming 5y agoMicro-services, for example, are pretty much all HTTP + JSON. The only place for HTTP is the browser and purely for historical reasons. Using it for anything server-server is a waste of network and CPU.
- xxs 5y agobut curl is so ==much== more than just http.
- chris_wot 5y agoWhich is why it is cURL and not cHTTP