Httpie: A CLI http client | Hacker News Reader

Httpie: A CLI http client

radek.io

391 pointsastro-49 comments

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).

But I fully agree, it's a complement.

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 did not know about jq, thanks!

Without jq, you can still pipe to python json.tool module:

$ curl http://domain.com | python -m json.tool

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.

Python does have ordered dictionaries, but the json decoder defaults to regular dictionaries. This is easily overridable with JSONDecoder.

Is there a one-liner you can use from the shell that preserves order?

Starting with 3.5[0] that's the standard behavior.

One liner-wise, you could create an alias

  echo '{"foo":12, "bar": 11}' | python -c 'import json as j, collections as c, sys as s; j.dump(j.load(s.stdin, object_pairs_hook=c.OrderedDict), s.stdout, indent=4)'

[0] https://github.com/python/cpython/blob/3.5/Lib/json/tool.py#...

jq is almost a full fledge programming language, like xquery, surprisingly powerful (in good and bad ways). Nice to port fragile sed-grep LoC.

I often use jq to extract data from REST apis, e.g. email addresses I need in a CSV file.

I wouldn't use this for scripting, but if I'm troubleshooting a rest endpoint or something, it might be useful.

Curl's api is turrible.

Not in my experience. wget is always available on default installs, whereas curl I have to specifically install.

curl + jq is a very nice combination. Here is the jq project page and a discussion on HN about it.

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

I concur - I've tried to like httpie, but always end up going back to curl since its syntax is permanently ingrained in my fingers.

So is vi. I still use emacs.

Using only tools based on ubiquity is rather short sighted.

Can we not argue about vi(m) vs. emacs? Thank you. :-)

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.

This is a highly repeated post on HN. https://hn.algolia.com/?query=httpie&sort=byPopularity&prefi...

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.

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.

Couldn't agree more. I have tools that generate a cURL and I'd love if I could transform them to httpie for personal use

There's also https://github.com/astaxie/bat which is heavily inspired by httpie but is written in Go so it's distributed as a single static binary.

Does it allow specifying indent spaces for json or html?

I've just checked the output of "bat --help" and currently it doesn't seem to have an option for that.

I use httpie all the time, and it's great.

One thing has always bugged me, maybe someone knows how to fix it.

This command works fine:

  $ http example.com

And http symlinks to the right binary:

  $ which http
  /usr/local/bin/http

  $ ls -l /usr/local/bin/
  ...
  lrwxr-xr-x  1 taylor  admin     31 Jun 25  2014 http -> ../Cellar/httpie/0.8.0/bin/http
  ...

But man shows a different executable:

  $ man http

  ...
  NAME
         http - Client-side implementation of the HTTP/1.1 protocol
  ...

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.

I usually do "man -a" when simple "man" doesn't hit the right man page.

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'm pretty sure it does not have a man page. Read http --help instead.

I cannot repro your man output on Ubuntu... I am wondering what 'man 1 http' will look like in OSX

Jeebus cripes, that's awesome.

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.

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.

Previously: https://hn.algolia.com/?query=httpie&sort=byPopularity&prefi...

Already made a PR for it... however, automated tools should really include a URL for the tool as part of the User Agent string.

    AGENT/##.## (url)

where `AGENT` is the identifier for the user agent, ##.## is the major/minor version, and url is the url for the tool/project/bot.

In this case, one minor tweak might be...

    HTTPie/%s (https://github.com/jkbrzt/httpie)

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.

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.

[0] https://chrome.google.com/webstore/detail/postman/fhbjgbifli...

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.

+1 for this. I have been using it for more than a year. Even just as a "shortcut" for curl it's really good!

To be honest, I am a little surprised to see it here because I thought everyone already knows about it.

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.

I first discovered it on HN several months ago, so it's definitely been here.

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.

How is this supposed to be pronounced?

From the README.rst file at https://github.com/jkbrzt/httpie :

  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.

This is a fantastic tool, I use it a ton to test REST apis and the like.

Every download tool wants to become a browser.

Reply on news.ycombinator.com