Live data from Hacker News

HTTPie: A cURL-like tool for humans

github.com

61–70 of 88 posts

Re: HTTPie: A cURL-like tool for humans

#61

Earlier quoted context omitted.

Gosh, what a horrible comment! The simple fact is that curl and wget's interfaces are bad, and everyone who learns to use them spends that 10 minutes. And then, if you're like me, respends that 10 minutes when I need to do something fancy again. If a new tool were to save 5 minutes (which this one does), that's 5 minutes saved on every use, which is probably a total of a few hours for me personally, and spread over t…

curl and wget might not follow Unix conventions all that well, but from the look of it neither does HTTPie. Thus the GP's point stands that this program offers little more than a stylistic change. And a bit of pretty printing, which you could (ideally) pipe into some syntax highlighting script or an editor to get the same effect. Don't read the docs with this thing, for example, and you'd wonder why it defaults to JS…

Still, you pay a one-time cost of reading the manual, then the ongoing benefit of using a nicer UI. With cURL you pay the one-time cost of reading its manual, but also pay the ongoing cost of dealing with its unintuitive, verbose, and generally less human-friendly UI.

JSON encoding is a sensible default these days for a tool to be used by humans, though I agree there's a good "principle of least surprise" argument for defaulting to plain HTTP POST. It would also be nice if it had a setting between "interpret response as JSON" and "uglify the response", but OTOH those additional formats are good opportunities for user-contributed patches.

Re: HTTPie: A cURL-like tool for humans

#62

Earlier quoted context omitted.

>on at least some occasions the Python client gets non-standard results, while curl and (Guido, forgive me) PHP do fine Ok, young one, here's the thing. If you see a problem like this then file a bug. Ideally write a test case. And if you're an overachiever, dig into the code and fix it. Any bug in an http client that reposts data is incredibly serious, and needs to be fixed. The other value in doing this is that you…

No offense taken. I did report this to the API maintainers, who couldn't make heads or tails of it. I didn't file a Python bug because I honestly don't think Python is the problem. But you are right, it is more responsible to pursue this until fixed rather than raise warnings.

Do you have a link to the report? I'd be interested to read the discussion.

Re: HTTPie: A cURL-like tool for humans

#63
post #15
post #5

It looks great! I see no reason to slight cURL, though. Its CLI was intended for humans.

It's not meant to be an insult on cURL. cURL is a great library/tool and supports way more than HTTP, but the command line interface simply isn't as convenient for common HTTP as it could be. The "for humans" slogan is borrowed from the underlying python-requests library and is meant to communicate that good UX is one of the top priorities of the project. Glad you like it!

You could just use our curlish wrapper (http://packages.python.org/curlish/) which just wraps curl directly. You get a nicer UI if you want but still the full power of curl.

Re: HTTPie: A cURL-like tool for humans

#65

"for humans" seems to have no better meaning than "for the OS X sensibility". In other words: this is a style change rather than a productivity gain. And the superiority of the style is not obvious - unless you just HATE the style of existing tools and need to be set apart. Most humans don't operate the command line or write scripts to begin with. Those who do, usually can handle wget " http://foo/bar . It took me al…

I couldn't disagree more. I wish I could disagree more, tough. Your comment shows a complete disregard for User Experience and User Interface, and this disregard is the reason why so much stuff simply "sucks" nowadays.

Re: HTTPie: A cURL-like tool for humans

#67
My main difficulties in using wget are in organizing output location (things like -nH, --cut-dirs, -P), choosing between -nc / -c / default (rename), error / retry policy (-T / -t), logging (-a vs -o), etc.

This tool doesn't really solve any of my actual problems. YMMV. It's less a cURL replacement than a web API invocation tool.

Re: HTTPie: A cURL-like tool for humans

#68

This is a nice curl and wget replacement that handles a bunch of modern use-cases without a lot of hard-to-remember command-line flags. That said, there is a broader problem of "hard-to-remember command-line flags" which I have personally solved using snippet management (I use notational velocity or command history, whichever is handiest). There is no doubt httpie's interface is a lot better, but it creates another p…

> People had a choice: either put up with an (admittedly) bad interface or write their own version in C.

That's totally false. libwww-perl was created 17 years ago and predates curl by a few years. There's nothing new about capable scripting languages and Unix.

Re: HTTPie: A cURL-like tool for humans

#69

"for humans" seems to have no better meaning than "for the OS X sensibility". In other words: this is a style change rather than a productivity gain. And the superiority of the style is not obvious - unless you just HATE the style of existing tools and need to be set apart. Most humans don't operate the command line or write scripts to begin with. Those who do, usually can handle wget " http://foo/bar . It took me al…

[deleted]

Re: HTTPie: A cURL-like tool for humans

#70
post #56

Everything on HN is just "hey, learn to use this complicated complex thing - in just 30 minutes! You'll be so productive with all your creative startups!" "Learn VIM essentials in this blog post!" "Never bother reading 'man curl'!" "Learn the basics of C in three easy steps!" Sometimes HN feels like a lifestyle magazine for people who dream of being PG. EDIT: Don't get me wrong, I too dream of having the same succes…

What's your criticism exactly? What kind of content would you personally like to see more of?
Post reply on HN