Nice. Ignore the haters, this is a wonderful _companion_ to curl.
As others noted, I'd revert to curl commands for sharing with others (or for performance-sensitive tasks like downloads or quick-and-dirty load generation) but this may become my go-to HTTP CLI for personal use -- if only because it looks like won't need to look at the man page every time I want to do much more than a basic curl -X <METHOD> <URL>. (But maybe that says more about me than curl/httpie.)
One neat feature to add would be a mode that accepts the curl syntax (or at least the common parts of it), that way all the curl examples and "Copy as curl" tools work with httpie as well.
Conversely, an option that accepts httpie syntax and outputs the corresponding curl command might be convenient as well. (But I guess at that point maybe httpie devolves into a command-line parser + pretty-printer that wraps around curl, but that may not be all bad either.)
I like using httpie for documentation, tutorials and blog posts because I feel it is more readable. I also really like how you can skip the whole "http://localhost/" bit for local development. Just "http :9200" for elasticsearch, "http :6543" for pyramid etc.
Agreed that curl is good for things that should be copied and pasted directly or for matters of distribution because it is guaranteed to be installed everywhere.
Would also love a httpie2curl converter for those times when testing in httpie and needing to distribute the requests to places without it.
I used to use this pretty frequently at a previous job that had a weird login flow. The nice part about httpie is the custom authorization implementations (verses chaining a bunch of curl/awk/sed calls to do the flow).
And yet, curl is always available, widely supported by various "Copy as curl" features in debuggers and proxies and it also makes zero assumptions about content-types of form data you might want to post, so it's always very clear what's going to be posted.
It also follows unix conventions in option placement and syntax, so there's never any cognitive hurdle to cross when the question arises where to put headers, where to put form data, where to put query string data, how to handle the case of query string data being supplied using overlapping methods and what the form data is encoded in.
It also doesn't force me to write json in yet another syntax that's command-line friendly. Instead I can just write json.
Yes. HTTPie looks nicer, but the wide availability of curl and the much more predictable syntax make it a better tool for my taste.
If I need formatted JSON output, I can always pipe the result in to jq.
You don't have to stop using curl because httpie is available. I find httpie very intuitive for my own use, but would share curl commands with other devs as it is ubiquitous.
I used to do this, but now I use jq. The thing about the Python version is that Python doesn't have ordered dictionaries, so the output isn't in the same order as the raw JSON. jq doesn't have that issue which is nice.
That wasn't really the point. I think they're saying that just because a tool is ubiquitous doesn't mean that it's objectively the best tool for the job in all cases. Just as vi and Emacs coexist, curl's existence doesn't make httpie pointless.
It's a nice tool to have, working in a hosting/managed services setting. I've aliased "get" to "http --headers get", just so I can fire that off quickly and take a look without even thinking about it.
Manpages are completely separate from executables. They reside in /usr/share/man (and perhaps /usr/local/share/man—not sure if that's used). Manpages for user commands are in the 1 category, so they'd be in /usr/share/man/man1.
If there is a manpage, it's possible that another manpage exists with the same name, but in a different category (such as a system call). In that case, running "man 1 http" will restrict man to only look for a user command manpage.
This looks like a man page from Tcl's http module. Perhaps httpie does not have a man page. Http is a very generic name, they should call the binary differently (maybe httpie?) to not conflict with other things.
I've been using Httpie as part of my daily development workflow for a couple of months now on multiple HTTP API projects and I have to say it's been tremendously helpful for iterating, testing, and debugging. I just setup a new machine at my work yesterday and I made sure to install this tool on it. Definitely recommended.
For querying HTTP APIs from the browser I use the postman[0] Chrome extension.
It can import calls from a curl command and RAML/WADL/Swagger files. It also supports OAuth1/2 authentication, which is neat.
Probably worth trying it out again, but the last I checked it was "new and shiny" but absolutely useless and unreliable piece of software. I don't remember now what exactly was the problem, but it was something pretty basic: I guess it was improper handling of non utf-8 encodings. Or something as frustrating as that.
I've been using this for quite some time and love it. My only minor complaint is that when redirecting to a file, it'd be nice if it defaulted to "--pretty=format" instead of "--pretty=none". (I always forget to specify "--pretty=format" the first time...)
i'm a pretty heavy curl user so i gave it a try. My humble verdict is that there is not enough benefit for the change in interface, to make it worth using. Now if it had a compatibility mode for curl cmd parameters and format, then that might be something i could use.
I've been using this for several months and it's now an indispensable tool for me. Maybe I just never learned enough Curl options, but I find HTTPie to be so much easier and more intuitive. Paired with jq, it makes my life much easier on a daily basis.
I've never seen it on HN before, and the Venn diagram intersection between "good ways to access a novel HTTP API" and "be on HN all day" is basically my only job at the moment.
There are a number of docker containers with httpie in them (I maintain one) as well if you don't feel like doing a native install, AND you're already using docker for things.
HTTPie (pronounced aych-tee-tee-pie) is a command line HTTP client.
The name, as written on the repository, is "HTTPie", and not "Httpie" like in the title of this post.
H-T-T-Pie, which I'd relate to it being written in Python, where the file extension and several other names have "py" (pronounced as "pie") in some form.
As others noted, I'd revert to curl commands for sharing with others (or for performance-sensitive tasks like downloads or quick-and-dirty load generation) but this may become my go-to HTTP CLI for personal use -- if only because it looks like won't need to look at the man page every time I want to do much more than a basic curl -X <METHOD> <URL>. (But maybe that says more about me than curl/httpie.)
One neat feature to add would be a mode that accepts the curl syntax (or at least the common parts of it), that way all the curl examples and "Copy as curl" tools work with httpie as well.
Conversely, an option that accepts httpie syntax and outputs the corresponding curl command might be convenient as well. (But I guess at that point maybe httpie devolves into a command-line parser + pretty-printer that wraps around curl, but that may not be all bad either.)