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.
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.
[+] [-] rodw|10 years ago|reply
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.)
[+] [-] chrstphrhrt|10 years ago|reply
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.
[+] [-] nerdwaller|10 years ago|reply
But I fully agree, it's a complement.
[+] [-] pilif|10 years ago|reply
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.
[+] [-] balac|10 years ago|reply
[+] [-] cellover|10 years ago|reply
Without jq, you can still pipe to python json.tool module:
$ curl http://domain.com | python -m json.tool
[+] [-] empath75|10 years ago|reply
[+] [-] kaonashi|10 years ago|reply
[+] [-] XorNot|10 years ago|reply
[+] [-] dpflan|10 years ago|reply
1. jq project page: https://stedolan.github.io/jq/
2. jq HN Discussion: https://news.ycombinator.com/item?id=9446980
This comment from the jq HN submission discusses httpie, jq, and httpie vs. curl: https://news.ycombinator.com/item?id=9447175
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] snockerton|10 years ago|reply
[+] [-] michaelcampbell|10 years ago|reply
Using only tools based on ubiquity is rather short sighted.
[+] [-] epalmer|10 years ago|reply
That said, I use curl and httpie. I am a casual user of both and love them both. I first heard about httpie on HN.
[+] [-] cacarn|10 years ago|reply
[+] [-] setheron|10 years ago|reply
[+] [-] vially|10 years ago|reply
[+] [-] karmakaze|10 years ago|reply
[+] [-] tedmiston|10 years ago|reply
One thing has always bugged me, maybe someone knows how to fix it.
This command works fine:
And http symlinks to the right binary: But man shows a different executable:[+] [-] organsnyder|10 years ago|reply
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.
[+] [-] takeda|10 years ago|reply
[+] [-] Sir_Cmpwn|10 years ago|reply
[+] [-] goodcjw2|10 years ago|reply
[+] [-] a3n|10 years ago|reply
The article says pip, I used apt-get which is probably somewhat behind. Either way.
EDIT: yep, the version in my repo was 0.8.0. I uninstalled and used pip, it's now 0.9.2.
[+] [-] andrewrothman|10 years ago|reply
[+] [-] sciurus|10 years ago|reply
[+] [-] tracker1|10 years ago|reply
In this case, one minor tweak might be...
It's a minor nit, but trying to find something based on "foo/version" alone isn't always easy enough when looking at your logs.[+] [-] omribahumi|10 years ago|reply
[0] https://chrome.google.com/webstore/detail/postman/fhbjgbifli...
[+] [-] krick|10 years ago|reply
[+] [-] msluyter|10 years ago|reply
[+] [-] leecarraher|10 years ago|reply
[+] [-] derelk|10 years ago|reply
[+] [-] goodcjw2|10 years ago|reply
To be honest, I am a little surprised to see it here because I thought everyone already knows about it.
[+] [-] patio11|10 years ago|reply
[+] [-] michaelcampbell|10 years ago|reply
[+] [-] toddmatthews|10 years ago|reply
[+] [-] newscracker|10 years ago|reply
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.
[+] [-] homulilly|10 years ago|reply
[+] [-] eccstartup|10 years ago|reply