HTTPie is a command line HTTP client, a user-friendly cURL replacement | Hacker News Reader

HTTPie is a command line HTTP client, a user-friendly cURL replacement

httpie.org

309 pointsgrhmc76 comments

This is one of the little known gems I recommend often. the readability difference is just amazing for me. On that note for those of us having to use Windows at the workplace there are a few things that make life easier:

1) Chocolatey (package manager)

2) HTTPie

3) ConEmu (Shell)

4) gow (Unix command line utilities in Windows)

5) WinMerge (win diff)

6) TortiseSVN

7) SourceTree (git)

Makes day to day stuff much smoother....

I've got a couple other utils I'd add to a list like this:

- kitty (ssh client, fork of putty) - visualwget (wget gui) - dsynchronize (dir sync)

Another great SSH client is SmarTTY.

I'm partial to PuTTYTray.

I came across this last week, a colleague wanted to open up an X window on his Fedora VM, shown in his windows box. SmarTTY just worked ootb, it was pretty amazing!

When I'm on Windows I use Cygwin ssh but for those who are more Windows aware, BitVise Tunnelier.

Another one - crossplatform http interception proxy like Fiddler - called mitmproxy. It has a great feature - it can transparently handle https traffic.

WinMerge is not that good. BeyondCompare is in a league of it's own when it comes with diff apps (it's commercial though).

I can vouch for the rest too....ConEmu especially is very very nice.

I've had it installed on a bunch of corporate boxes and never used it and I'm not sure if anyone used it.

Even though it's a bit crash happy on windows and the gtk file picker sucks on windows for my uses meld was the most useful(at least now they have a packaged version for windows - http://sourceforge.net/projects/meld-installer/ - so you don't have to package it yourself). It's simple, good looking, highlights the difference between 2 slightly modified lines, has support for comparing directories, and allows in-place editing.

I prefer Meld on Linux and yes on the odd day, Windows.

I have moved away from windows and miss Fiddler the most. It's ability to record, filter, edit and replay requests made debugging a breeze.

Try the proxy in Burp Suite. The free edition lets you do most of what you can do in Fiddler. More powerful in some ways, rougher around the edges in other ways.

I like Mitmproxy. http://mitmproxy.org

Charles Web Proxy? Not free, but I've been using it very reliably on all platforms for at least 3 years now. :) A nicely polished bit of software. Free 30 min "trial mode" and no-cost upgrades, if it helps. Otherwise I've also used mitmproxy, or for some things, the Net panel of Chrome Dev Tools.

They seem to have Fiddler for Mac and Linux now (alpha version) http://fiddler.wikidot.com/mono

I've been looking forward to having WinMerge on Linux for so long. I haven't found a good alternative on Linux which can do quick side-by-side comparison just by pasting from clipboard.

If you're on vim side - vimdiff does comparison just right. Though one'd need to tweak it to support comparing stuff from clipboard.

You (and anyone reading this great list of recommendations) should try cmder. It's a customized build of ConEmu with lots of goodies thrown in.

http://bliker.github.io/cmder/

Can confirm, cmder is great, it makes console use on Windows bearable.

8) FileSearchEX for searching through source code files

Git Extensions for git are very nice too

You don't need gow if you are using msysgit right?

I'd add VirtuaWin for virtual desktops

and of course Emacs for Windows

I'd just wrap a simple program around curl to improve its argument passing complexity if that's your pain point but I wouldn't go on rewriting an HTTP client.

Curl is a very mature code base by now and that's something to appreciate. It handles all the edge cases well and has dealt with all the mess that you'll discover over time.

httpie uses requests[0] under the hood, a well respected python HTT library. See https://github.com/jakubroztocil/httpie/blob/77955c9837259b1...

Httpie doesn't come close to Curl in terms of features. Its selling points are colourised output (using pygments) and (slightly) better json formatting. Here's an unobstructed side by side comparison for the same request: http://i.imgur.com/Bj2wRkq.png

While it won't replace Curl, it can prove quite useful while testing APIs.

Why is the order of the headers different between those two examples?

I haven't looked at any code, but I would strongly suspect that it's because either HTTPie or python-requests is using a plain dictionary instead of an ordered dictionary under the hood.

That would appear to be a bug to me. When you want to see the headers of such a transaction you want to see them in the order in which they left the server.

I checked the server and it looks like CURL has it right.

Colorizing is one thing, reordering is quite another, debugging tools should show the situation with as much fidelity as possible.

Requests does use an ordered dictionary for handling headers.

It should as order is important.

www.ietf.org/rfc/rfc2616.txt

4.2 Message Headers

The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields.

Yes, if you're implementing a client or server, you should not depend on the order of the headers. Completely separately, when I have a command line client for debugging, I want to see the request and response exactly as they were sent/received, respectively.

> Instances of the same path and name will overwrite each other, with the latest instance taking precedence. Instances of the same path but different names will add additional mappings.

> When sending cookies to a server, all cookies with a more specific path mapping should be sent before cookies with less specific path mappings. For example, a cookie "name1=foo" with a path mapping of "/" should be sent after a cookie "name1=foo2" with a path mapping of "/bar" if they are both to be sent.

http://curl.haxx.se/rfc/cookie_spec.html

Requests might but that's irrelevant. Requests is built on top of urllib3 which is built on top of httplib which does use a plain dict. Also the relevant RFC says order is irrelevant.

Debugging starts with having an accurate representation of what is going on.

Ok, so this tool is only for all the situations in which you don't care about header order.

Should body chunks when using chunked encoding have their headers spread throughout the body, to have as much fidelity as possible?

Or would you like the body to always appear whole regardless of transfer type?

HTTPie sorts them before outputted.

In the readme: https://github.com/jakubroztocil/httpie#colors-and-formattin...

In the code: https://github.com/jakubroztocil/httpie/blob/master/httpie/o...

The user agent is truncated in HTTPie.

Exactly. Seems like a lot of the verbosity that is saved is simply implicitly assuming -i -H 'Content-Type: application/json; charset=utf-8'

I seem to spend my every waking moment reporting defects for HTTP APIs. HTTPie's interface is far more intuitive than cURL's, and pretty-printed responses are a kindness not just for me but for the people who have to read the bug reports, too.

I'm not sure about httpie but using curl with jq also gives nice formatted and coloured responses.

  curl ... | jq '.'

jq is awesome, particularly if you need to filter or otherwise process JSON, but the great part about httpie is that it works with just about everything so you don't have to remember a different filter chain for each type of content.

It uses pygments which means you also get nested formatting for e.g. CSS or JavaScript inside an HTML document.

Awesome, thanks!

You could use our Share URLs which would let the people you share defects with reproduce them for themselves: https://www.runscope.com/docs/sharing

Determining the type of an argument by looking up the presence of ':', '=', or '==' is brilliant. I liked it.

It can also be used to replace Wget, which not only breaks a multibyte filename sometimes, but also requires the --content-disposition option to handle the Content-Disposition header.

At first I thought, what is so unfriendly about cURL? Then I saw the screenshot that shows a comparable cURL request behind the HTTPie request and I'm convinced.

That was my first thought, too. Then I saw the colorized output and I'm convinced, too.

Isn't the HTTpie command simpler because it uses defaults for the content type and charset? If Curl did the same (not sure why it should because not everything is JSON/UTF-8), the command would be about as short as the HTTPie one.

This is probably different for different people, but I find myself constantly looking up the right flag for controlling a part of a request with curl even though I use it a lot. Having the command line be smarter about interpreting which argument is which seems like a productivity gain to me.

Somehow I used to hate curl because I began using it through the PHP Curl extension,which has the most horrible API(no,the other API for HTTP requests in PHP is even worse, it creates adhoc variables,yes variables can appear like that in PHP which leads to "variable name collisison"... ).

But with time,using it in the shell it happened to be quite powerfull for testing apis.

HTTPie coloring is a plus,does it work with XML too?

While I don't think it will EVER replace curl, it does seem like a fun piece of software to play around with. Great job!

This is amazing! Will definitely be switching away from using curl. I put a the basic examples here to easily play with httpie http://runnable.com/U5wOrMxHLYsVkYbX/basic-httpie-examples-f...

The sessions, the wget-like download mode, the binary detection, the upload capabilities... there is a lot to like here. I will definitely be checking this out. Thanks for posting!

Instead of curl I was usually writing https://github.com/kennethreitz/requests

That's what httpie uses internally: https://github.com/jakubroztocil/httpie/blob/77955c9837259b1...

Tried it just now and I see non-ascii characters messed up, while curl shows that page fine. Probably there's some case-specific reason for that, but still…

Now if I could pipe the request from Sublime Text and get the results back in a buffer it would be awesome to deal with JSON. Any idea?

Big fan of this one. HTTPie is a lovely replacement for cURL, especially when you just want to quickly test a JSON API.

Is there a curl replacement written in Node (for us Windows users who don't have a proper curl out of the box)?

D'oh! HTTPie doesn't support SNI

If you use Python 2.x and need to talk to servers that use SNI (Server Name Indication) you need to install some additional dependencies:

$ pip install --upgrade pyopenssl pyasn1 ndg-httpsclient

Ah, I'm not a python man. Thanks for the heads up

I use this tool on a regular basis and just love it. Thanks for building HTTPie :)

Is there any chance get this into Homebrew for an easier installation on Mac?

I just installed it on my mac by doing $ sudo pip install httpie

It was not too tricky

Sure, but i dislike installing other tools like pip just for a single tool.

As a python dev, I use pip all the time. My first thought was, "nice, just use pip." I appreciate your comment because it helps remind me that people approach problems from different frames of mind.

HTTPie has just been added to Homebrew:

    $ brew install httpie

Tried it, works great! Nice work!!

I will keep using wget.

HTTP::Tiny

Poor choice of name. All I can see is HTTP Internet Explorer.

ditto. HTTPy would have been better, methinks.

'hc' might have made it successful, at least then it would have one benefit over curl.

Reply on news.ycombinator.com