Hacker News Reader

Comment by benatkin | Hacker News Reader

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!

I don't think it's the most obvious kind of good UX, but rather good UX for people who value expressiveness, like ruby programmers. The items that change meaning based on symbols are quick to type, but it comes at the cost of clarity. curl's paramters aren't very clear either, and since it supports more than just HTTP, it's harder to go through the man page with all that it supports. I think there's still room for one that uses option names/letters to differentiate between headers and body properties rather than symbols.

It is UX with the inflection of Apple's Human Interface guidelines, which have always been a mix of technical guidance and branding/marketing guidance (as opposed to pure, wonky, research-based, specifically tailored ergonomics, which defines usability relative to specific tasks and audiences, some of which may be highly technical and appreciate complex tools).

Apple discovered that words like "usability" and "human" are very powerful ways of framing competing products as unusable garbage not fit for human consumption. And they worked very hard and were very successful at fitting these words to their brand. This cuts the legs off any competing marketing. If you were a competitor the best you could say to this was something like "we have more games" or "we are cheaper" or "we have higher clock speeds" or even "you have more choice." Meanwhile the audience glazed over and felt threatened. Apple told the same audience that actually they were better than those hobbyist losers wasting all their time because they had bigger issues to worry about, they were discerning and frankly they were cooler.

Marketing is a high art and Apple is sitting on top of huge mountains of money after fighting Total War for decades. Good for them.

When it comes to evaluating libraries and command line tools, invoking the words 'human' and 'usable' still indicates that the developers and users of the old one are losers focused on irrelevancies, with huge amounts of time to waste on tools that are just plain unusable for anybody and unfit for human consumption.

Anyhow, there is more to this UX than just what is nice to use.

You've done a wonderful job of expressing my sentiments on this issue. What annoys me even more is the degree to which projects like Gnome copy Apple's design decisions that make their tools less effective for "Power Users".

By the way, the "Power Users" term is used to marginalize people who are willing to learn to use their tools. The results of using this term in this way have IMHO slowed the growth of the computing industry.

Thanks for the feedback!

I tried to come up with syntax that would make the most common tasks (i.e., sending JSON objects, submitting forms, setting headers, etc) as easy as possible and also feel "natural". The reason for the chosen style is that it quite corresponds to the actual HTTP request being sent. For example, if you want to send a PATCH request with a custom header and a form field data:

    PATCH /patch HTTP/1.1
    X-API-Token: 123
    Host: httpbin.org
    Content-Type: application/x-www-form-urlencoded; charset=utf-8

    foo=bar

You can simply copy the header (X-API-Token: 123) and the data (foo=bar) and paste it to the terminal:

    http --form PATCH httpbin.org/post X-API-Token:123 foo=bar

It's not as obvious as '--request PATCH --header X-API-Token:123 --form foo=bar', but on the other hand, the command doesn't include almost anything that wouldn't become part of the actual request, which makes it short and easy to focus on what's important.

Hmm, that makes more sense. If it isn't already in the README or man page, it might be a worthy addition.

I suggest you add an option where you can start off with a bare request.

Is there a way to have it construct the query string when you are doing a GET request? Also is there a way to have it construct a query string when you have a JSON or form body? Might be something to add below the description of items, as something that doesn't fit into that list but is related. Perhaps -q page=2 -q rpp=20 would be a good way of saying it.

> Hmm, that makes more sense. If it isn't already in the README or man page, it might be a worthy addition.

Good point, I'll add it to the README.

> Is there a way to have it construct the query string [...]

Not yet, but it's being already discussed here:

https://github.com/jkbr/httpie/issues/61

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.

Reply on news.ycombinator.com