81–90 of 154 posts
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 thi…
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?
The page even sort of acknowledges this... saying you manage your environments with environment variables. It doesn't mentioned how to extract data from the response, just jq for syntax highlighting. No explanation of combining these two into any sort of cohesive setup for managing data through flows of multiple requests. No mention anywhere on the page of working with an OpenAPI spec... many of the tools provide easy ways to import requests instead of manually reentering/rebuilding something that's already in a computer-readable format.
So the tl;dr here is "use cURL, and then rebuild the rest of the functionality in bash scripts you idiot".
I went down this path of my own accord when Insomnia was no longer an option. I very quickly found myself spending more time managing bash spaghetti than actually using tools to accomplish my goals.
That's why I use a full blown dedicated API client instead of a HTTP client. (Not Postman though. Never Postman.)
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...
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.
After decades it should have been obvious by now that the vast majority of users prefer GUIs.
My response to this article is the same one I have to anyone out here screaming "it's so easy to just do it my way!": if it's so easy, then do it for me!
The ffmpeg fans are the loudest screechers I've found, in this area. They'll point to the trainwreck of a UX that is Handbrake as an example of GUI for terminal commands. And, look - command line utilities are great and Handbrake is a super good product that functions well and does more than I'd ever want it to. But neither of those things are the same thing as having good UX.
If it's so easy to compile a bunch of shell scripts and store them in a directory in a git repo, then package together a bunch of them that every dev would need, sprinkle in a few with placeholders that most devs would need (with some project-specific input), and then serve them to me in a composable GUI that, in real time, builds the command to be run in my shell. Let me watch the clicks edit the command, and then let me watch the "submit" execute the command. There's no surer way for me to learn exactly what commands I need than to see them all the time. And if I have to learn them (so that I can use them) BEFORE I've seen them - in context - a few times at least, then I'm going to have a much harder time remembering. UX, when done right, helps the user.
Put simply: if I can do everything I would be able to do with postman using curl, then I should also be able to wrap curl in a thin DearImgui window that is reactive to user input. And if it's as easy as the author says, their time would have probably been better spent just making the GUI wrapper app and presenting it as a way to get better with curl, rather than writing an edgelordy article about it.
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?
If you're doing a lot of requests for testing or some other purpose I could see an argument for a graphical interface. Curl is a masterpiece but it's not that simple to use. But again, we're in $current_year and I'd be surprised if "hey Claude, can you cook up a curl request to do this and that" doesn't work.
Just save your requests in separate script and organize them.
And now you can run them from anywhere, including other scripts
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?
Using curl, how would I send a collection of frequently used requests to a coworker? Plain text file?
users/create.sh, users/delete.sh, etc
Earlier quoted context omitted.
Inversely, plenty of people use GUIs for all of those things.
Yes, I agree, and have no qualms with people who prefer GUIs. But to say that "majority of users (developers?)" prefer GUIs seems outlandish at best.
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.
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. 1 - https://httpie.io/ 2 - https://rs.github.io/curlie/
curl may be outdated but at least it's a survivor. the alternatives (esp. the suspicious httpie grift) won't make it.
The issue with "survivor" software is that UX cannot be refined due to legacy support and that's what's great about curl itself is that libcurl and CLI front-end are separate tools allowing for alternative modern front-ends.