I've been using curl, like forever. I don't understand the preoccupation for using postman, et. al. -- why pay for something that literally requires a little bit of light RTFM?
While I like curl, this is highly subjective, some people just prefer a GUI that can guide you and/or be visually explored.
This whole piece also reads like someone is quite angry at people preferring a different workflow than them. Some aspects, like shell history, are also not the magic bullet they propose here as it doesn't, e. G., cover the actual responses.
Curl's ability to do almost everything is a minor curse here too as it means that any documentation (man pages, options help) is very large.
Curl and jq are plenty to get the job done. As the author points out, you can capture all your curl commands in scripts and then orchestrate with other scripts for testing purposes. On top of all the benefits the author has already mentioned, you get a boost if you're doing your development work in a VM, as I do. It's less you have to install, configure, and manage. Sure, that can be automated, but it's just more stuff you have to take care of and the longer you have to wait for a fresh VM to be ready.
Using -X POST is often wrong as it "changes the actual method string in the HTTP request [... and] does not change behavior accordingly" (Stenberg, 2015).
Although, it is correct for the article's mention of "Send POST requests"... just that typically people don't send POST requests out of the blue with no data.
I am a total newbie to curl. I am so excited to come across this post. Thanks, op! I want to use curl to send json and xml requests instead of using Postman and SoapUI while also using a jks file which stores a certificate for secure connection to API.
I use httpie (not httpie actually, https://github.com/ducaale/xh but it has the exact same ux). For the life of me, I can't remember curl flags for some reason. Even fucking -X POST... Sending JSON is pain too.
For quick and easy http requests, httpie has been fantastic.
I might get lit on fire for this, but I don't find manpages very easy to use. If want to quickly remember an option or argument order, I am met with a wall of text.
Does anyone have tips for how to make it more useful? Maybe I could grep better for options? For example in the link, the author lists out common curl commands like making a POST request or adding a header. If you tried to look through the manpage for this, this would take a long time.
There's another utility called tldr that does a better job of this by providing common usage examples that almost always instantly give me what I need, but its not nearly as comprehensive as man.
I find man pages to be useful when I’m already familiar with the command or topic. For long man pages, I usually get on fine by `grep`ing for relevant key-words.
I agree that they are daunting and not so helpful for users who are new to the command or topic. They usually lack a quick-start guide with examples that give the user a starting point to build upon.
Anyhow, after hearing about `tldr` for close to a decade, your comment inspired me to install it. When I tried running `tldr curl`, I was delighted to learn something new and useful:
# Resolve a hostname to a custom IP address, with verbose output (similar to editing the /etc/hosts file for custom DNS resolution):
curl --verbose --resolve example.com:80:127.0.0.1 http://example.com
Curl's UX is very dated and I wouldn't recommend it to any new user. Use many alternatives like httpie [1] or something like curlie [2] which is just an UX wrapper around the same libcurl. Httpie also has a postman-like web interface.
Does anyone have suggestions for when I need to use bearer auth and the token is super long?
With curl I end up finding the command becomes hard to read, even taking advantage of backslashes. With Postman, it tidily hides the token out of the way on a separate tab and gets out of my way.
Curl is great for running individual API calls, API clients are great for when you're actually working on the API or architecting an app with one. Not that there are things one can't do with API development from the CLI, but there is a lot more to API clients than that feature list (it doesn't even include anything around stuff one might want to do with openapi definitions!) and by the time you string it all together you get why people like the tool that did that for them instead.
It's clear at this point that terminal apps have lost to GUIs, but cURL is the one place where I think that's a shame. cURL /always just works/. It is predictable, consistent, transparent, and pretty easy to use in its simple forms, but with plenty of room for complexity if you wish to go the far. There's a reason libcurl is in everything from automobile infotainment systems to toasters. I'm glad to use a GUI over libcurl that doesn't also need a cloud to work, but at the end of the day, I find myself piping cURL to jq more than almost anything else.
Way back when Postman was but a mere Chrome plugin, I spent a lot longer than I'd have liked fighting with a request that should have been logging GET requests but wasn't. Imagine my surprise when I found that it was following Chrome's caching rules and not actually making my requests despite me intentionally firing off those requests. If only I had just used cURL...
> Now everyone's downloading 500MB Electron monstrosities that take 3 minutes to boot up just to send a fucking GET request.
While curl is fine, most of the time I use the REST Client extension in VS Code. While VS Code is an Electron monstrosity, assuming you already have it, that extension is less than 3MB.
Even the full-feature GUI extensions like Thunder Client are scarcely bigger.
Hate VS Code, and never let your hands touch anything other than vim or emacs? Fine, there's a number of extensions that run in the browser that do the same thing.
36 comments
[ 3.6 ms ] story [ 50.6 ms ] threadDoes anyone actually enjoy this uhm style of writing?
You define all your requests in a plaintext format and can inject variables etc... plus the name is kinda funny.
While I like curl, this is highly subjective, some people just prefer a GUI that can guide you and/or be visually explored.
This whole piece also reads like someone is quite angry at people preferring a different workflow than them. Some aspects, like shell history, are also not the magic bullet they propose here as it doesn't, e. G., cover the actual responses.
Curl's ability to do almost everything is a minor curse here too as it means that any documentation (man pages, options help) is very large.
Although, it is correct for the article's mention of "Send POST requests"... just that typically people don't send POST requests out of the blue with no data.
(Clarified regarding certificate)
For quick and easy http requests, httpie has been fantastic.
https://github.com/httpie/cli https://github.com/ducaale/xh
[1]: https://curl.se/docs/manpage.html#--json
Does anyone have tips for how to make it more useful? Maybe I could grep better for options? For example in the link, the author lists out common curl commands like making a POST request or adding a header. If you tried to look through the manpage for this, this would take a long time.
There's another utility called tldr that does a better job of this by providing common usage examples that almost always instantly give me what I need, but its not nearly as comprehensive as man.
I agree that they are daunting and not so helpful for users who are new to the command or topic. They usually lack a quick-start guide with examples that give the user a starting point to build upon.
Anyhow, after hearing about `tldr` for close to a decade, your comment inspired me to install it. When I tried running `tldr curl`, I was delighted to learn something new and useful:
1 - https://httpie.io/
2 - https://rs.github.io/curlie/
With curl I end up finding the command becomes hard to read, even taking advantage of backslashes. With Postman, it tidily hides the token out of the way on a separate tab and gets out of my way.
Way back when Postman was but a mere Chrome plugin, I spent a lot longer than I'd have liked fighting with a request that should have been logging GET requests but wasn't. Imagine my surprise when I found that it was following Chrome's caching rules and not actually making my requests despite me intentionally firing off those requests. If only I had just used cURL...
While curl is fine, most of the time I use the REST Client extension in VS Code. While VS Code is an Electron monstrosity, assuming you already have it, that extension is less than 3MB.
Even the full-feature GUI extensions like Thunder Client are scarcely bigger.
Hate VS Code, and never let your hands touch anything other than vim or emacs? Fine, there's a number of extensions that run in the browser that do the same thing.