Now you have syntax highlighting and JSON parsing. Total install size: ~10MB. Total startup time: instant. Total RAM usage: negligible. Total feelings of superiority: immeasurable.
As someone who often does curl API requests and also come up to idea of putting them in jq — I felt superior just by reading this, thank you
I really like that the link at the bottom of the page says “check out more stuff you should be using” but that URL takes you to a page where the curl article is the only link.
The low-tech version of it is that there is a certain technical way of asking computers for stuff, usually across the Internet. To do that as a human, for instance to build a system that can ask or answer these questions, there are a few different tools.
One is Postman, which is a fancy, graphical tool that essentially loads a full browser for interacting with parts of the question, sending it and displaying the answer. Of course, it’s a commercial product, so some nice features are locked behind paywalls. The full browser also requires more memory and more time to load.
Another is cURL (alias curl), which is a command line tool, meaning you just enter the various parts of the question as text. It’s a little less convenient for more complex questions to remember how to specify the question’s parts and adjust them, because instead of a nice table where you enter them, you have to type it in text, but you can use various other features of the command line to make it easier for yourself. In some cases such tools may have advantages over the graphical ones, allowing you to do things the other can’t do (or at least not easily).
The whole page is a rant about people using the heavier and commercial graphical tool instead of the lighter and freely available command line tool. It’s a tongue-in-cheek continuation of an old argument in some software developer circles, where you will have people who prefer to use certain graphical tools and others that not just prefer command line tools (or generally text-based code), but also feel like everyone should just use them instead. For some, that’s just friendly banter. For others, it’s a deeply ideological conviction.
Personally, I’d suggest that people use whatever works for them and their team. For example, I have little choice but to use a mostly graphical tool because I work together with people who don’t have the time to learn the text-based options. They might be a great tool for me, but if my work is unusable to others, that makes it harder to work together (and accordingly means that I’d be stuck doing everything myself, which I frankly don’t have the time for).
Dope, thanks for the ELI5, really appreciate it. I did look up curl and postman after the fact and was able to understand some of the context. What elude me are the specifics, relating to the commands in question. But I can’t expect having any understanding of it without having studied networking, I suppose. That’s fine. Cheers !!
Technically, it’s not so much networking (though parts of it are) as development of webservices and -applications.
Most of the stuff you do with these tools happens in the application (the actual information of the question and answer) and some in the presentation (how the question and answer are phrased), where you don’t generally worry about the actual transport of your question across the network.
Basically, if you’re asking someone for the time, “what’s the time?” would be the application data, while the presentation would be “hour and minute in 24h format” (or some shorthand for that).
The actual network part would be how you figure out who to ask, how you open the conversation (“Excuse me,”) or how you transmit the question (speech, text message, written letter) in the first place, but if we’re talking about asking for the time, we usually just take those communication basics for granted.
If you would like me to, I could try to explain more about the various options and parts of these requests (“questions”) in low-tech terms. I don’t think you need extensive knowledge about networking or software development to grasp the basics, if you’re interested (and I manage to translate it well enough).
ah ok, yeah, thanks for reframing. I’m not sure if the natural language approach is best, but that might just be me, I never resonated too well with this kind of high level analogies. I do appreciate the effort though. I didn’t realize this had to do with web development exactly. So the networking part is abstracted away ?
Just use curl
As someone who often does curl API requests and also come up to idea of putting them in jq — I felt superior just by reading this, thank you
I feel bad that I read that page in Chrome. I’m a failure of a techie.
Tomorrow I must atone by teaching more students terminal commands. Maybe using web API calls with cURL. Or get and some eviloverlord.com quotes?
Reminded me of motherfucking website
This website is wonderful
I really like that the link at the bottom of the page says “check out more stuff you should be using” but that URL takes you to a page where the curl article is the only link.
“more coming soon. Or not. I don’t owe you shit”
A majestic site indeed. Bravo sir.
I enjoyed every bit of it [=
the hostility is hilarious 😂
especially since I had no idea what any of it means 😂 and yet it manages to sound so obvious
The low-tech version of it is that there is a certain technical way of asking computers for stuff, usually across the Internet. To do that as a human, for instance to build a system that can ask or answer these questions, there are a few different tools.
One is Postman, which is a fancy, graphical tool that essentially loads a full browser for interacting with parts of the question, sending it and displaying the answer. Of course, it’s a commercial product, so some nice features are locked behind paywalls. The full browser also requires more memory and more time to load.
Another is cURL (alias curl), which is a command line tool, meaning you just enter the various parts of the question as text. It’s a little less convenient for more complex questions to remember how to specify the question’s parts and adjust them, because instead of a nice table where you enter them, you have to type it in text, but you can use various other features of the command line to make it easier for yourself. In some cases such tools may have advantages over the graphical ones, allowing you to do things the other can’t do (or at least not easily).
The whole page is a rant about people using the heavier and commercial graphical tool instead of the lighter and freely available command line tool. It’s a tongue-in-cheek continuation of an old argument in some software developer circles, where you will have people who prefer to use certain graphical tools and others that not just prefer command line tools (or generally text-based code), but also feel like everyone should just use them instead. For some, that’s just friendly banter. For others, it’s a deeply ideological conviction.
Personally, I’d suggest that people use whatever works for them and their team. For example, I have little choice but to use a mostly graphical tool because I work together with people who don’t have the time to learn the text-based options. They might be a great tool for me, but if my work is unusable to others, that makes it harder to work together (and accordingly means that I’d be stuck doing everything myself, which I frankly don’t have the time for).
Dope, thanks for the ELI5, really appreciate it. I did look up curl and postman after the fact and was able to understand some of the context. What elude me are the specifics, relating to the commands in question. But I can’t expect having any understanding of it without having studied networking, I suppose. That’s fine. Cheers !!
Technically, it’s not so much networking (though parts of it are) as development of webservices and -applications.
Most of the stuff you do with these tools happens in the application (the actual information of the question and answer) and some in the presentation (how the question and answer are phrased), where you don’t generally worry about the actual transport of your question across the network.
Basically, if you’re asking someone for the time, “what’s the time?” would be the application data, while the presentation would be “hour and minute in 24h format” (or some shorthand for that).
The actual network part would be how you figure out who to ask, how you open the conversation (“Excuse me,”) or how you transmit the question (speech, text message, written letter) in the first place, but if we’re talking about asking for the time, we usually just take those communication basics for granted.
If you would like me to, I could try to explain more about the various options and parts of these requests (“questions”) in low-tech terms. I don’t think you need extensive knowledge about networking or software development to grasp the basics, if you’re interested (and I manage to translate it well enough).
ah ok, yeah, thanks for reframing. I’m not sure if the natural language approach is best, but that might just be me, I never resonated too well with this kind of high level analogies. I do appreciate the effort though. I didn’t realize this had to do with web development exactly. So the networking part is abstracted away ?