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 usually plop the response in a file and nvim that. Or write “3 lines of python” if I need anything more complex.
EDIT:
Never tried jq but read up on it a little, seems hella powerfull. Also, in my workplace postman is the default tool, which I find infuriaring as hell.
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 ?
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.
Without knowing your level of technical background, I defaulted to the same kind of analogy I use with family. If that isn’t the best approach for you, I’m happy to try a different angle.
So the networking part is abstracted away ?
Yes, mostly.
For a brief excursion, the rough gist of networking is that the world wide web is just a bunch of connected computers, which is where the web analogy is from. To get a message to a specific computer, you first have some links that get your data packets from one node to the next. Then you have a routing protocol that figures out which node to send to next (IP being the most common one).
Then you have a transport protocol that prepares the packets to send on one end, reassembles the full message on the other if it had to be split up into multiple packets and checks that the contents look intact. In the case of TCP, it also establishes a connection to verify that all packets actually have arrived. In the case of UDP, it’s more like that online retailer that sent my parcel without tracking and didn’t care when it disappeared. Still mad about that. Anyway.
Transport doesn’t care how routing works. A computer directly connected to yours is no better than one halfway across the world, aside from being faster to reach. Likewise, routing doesn’t care how the packets get across. Whether by WiFi, optic fiber or SD card strapped to a homing pigeon – so long as the next node gets the packet, the job is done.
There are cases in web development where you do care about the transport protocol, but for making HTTP requests like you do with curl, you generally use a standard set of protocols (TCP/IP) and trust the network stack to get your messages there and back again. All you need is the address or the name (in which case, again, you trust the network to figure it out) and the actually relevant application info.
For this comment, my app knows the lemmy server to send to and the authentication token it uses to prove I’m actually @[email protected], so it bundles the ID of the parent comment I’m responding to and the body of my message up into a request, adds that authentication token and sends it to the server. How it gets there? Not Voyager’s business.
If I had a token, the exact recipient address and whatever metadata it requires, I could probably send the comment via curl too.
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
curl | jqis like the web equivalent ofcat | grepBut that’s a useless use of
cat.I usually plop the response in a file and nvim that. Or write “3 lines of python” if I need anything more complex.
EDIT:
Never tried
jqbut read up on it a little, seems hella powerfull. Also, in my workplace postman is the default tool, which I find infuriaring as hell.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 [=
Reminded me of motherfucking website
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?
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 ?
Without knowing your level of technical background, I defaulted to the same kind of analogy I use with family. If that isn’t the best approach for you, I’m happy to try a different angle.
Yes, mostly.
For a brief excursion, the rough gist of networking is that the world wide web is just a bunch of connected computers, which is where the web analogy is from. To get a message to a specific computer, you first have some links that get your data packets from one node to the next. Then you have a routing protocol that figures out which node to send to next (IP being the most common one).
Then you have a transport protocol that prepares the packets to send on one end, reassembles the full message on the other if it had to be split up into multiple packets and checks that the contents look intact. In the case of TCP, it also establishes a connection to verify that all packets actually have arrived. In the case of UDP, it’s more like that online retailer that sent my parcel without tracking and didn’t care when it disappeared. Still mad about that. Anyway.
Transport doesn’t care how routing works. A computer directly connected to yours is no better than one halfway across the world, aside from being faster to reach. Likewise, routing doesn’t care how the packets get across. Whether by WiFi, optic fiber or SD card strapped to a homing pigeon – so long as the next node gets the packet, the job is done.
There are cases in web development where you do care about the transport protocol, but for making HTTP requests like you do with curl, you generally use a standard set of protocols (TCP/IP) and trust the network stack to get your messages there and back again. All you need is the address or the name (in which case, again, you trust the network to figure it out) and the actually relevant application info.
For this comment, my app knows the lemmy server to send to and the authentication token it uses to prove I’m actually @[email protected], so it bundles the ID of the parent comment I’m responding to and the body of my message up into a request, adds that authentication token and sends it to the server. How it gets there? Not Voyager’s business.
If I had a token, the exact recipient address and whatever metadata it requires, I could probably send the comment via curl too.