The UI for curl is awful (--request to change the method??) and wget's is only slightly better, but they do have the advantage of ubiquity, and it's often useful to email/Skype complete curl or wget command lines about the place to explain how to use an API, or demonstrate problems. (e.g. Stripe and others document their API in terms of curl commands: https://stripe.com/docs/api. ) I do wish the curl UI was better, b…
HTTPie: A cURL-like tool for humans
31–40 of 88 posts
Re: HTTPie: A cURL-like tool for humans
#32I was looking for something like this a while back and found a useful firefox plugin called Poster ( https://addons.mozilla.org/en-us/firefox/addon/poster/ ). It's useful for testing a RESTful api without creating any front-end code to handle the requests. Or anything you can do with cURL just simpler.
I wrote a similar one for chrome https://chrome.google.com/webstore/detail/cdjfedloinmbppobah...
https://chrome.google.com/webstore/detail/aejoelaoggembcahag...
Re: HTTPie: A cURL-like tool for humans
#33In 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 all of a few seconds to start using wget and all of 10 minutes to have access to fancier features. (But the truth is that a certain level of complexity really just wants a script rather than ad hoc commands).
So here is a new tool, and it looks nice. But it doesn't at all relieve me from having to learn syntax and conventions - I still have to go to a doc/manpage and read that same kind of technical prose. So the only effective difference is that now I am using different punctuation, like @filename and -b. But the use of this "@" character is not really consistent with anything else.
So the tool is fine and I am sure people will use it but the competitive advantage is incredibly thin and the project smacks of NIH.
If curl and wget are not for humans then what are they for? People who do not have that magical design sensibility. Lame code-monkeys without vision, who are not creative and different. Soulless agents of the man.
This emphasis on branding over substance irks me quite a bit.
Re: HTTPie: A cURL-like tool for humans
#34That 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 problem (again, which is somewhat universal) of installing, learning and remembering to use a new tool. This is a non-trivial problem that is a key concern for anyone evaluating a new tool, and it's a problem that only really gets solved with ubiquity.
Finally, an observation that so many of our "traditional" command line tools pay no attention to usability because, at least back in the day, the problem they solved was hard. People had a choice: either put up with an (admittedly) bad interface or write their own version in C. The individual cost of learning a bad interface outweighed the cost of rewriting the tool, and so standard tools were born.
And now, decades later, new generations are stuck having to learn needlessly obtuse interfaces to standard tools. We have a situation where newcomers pay the cost of developer UI laziness in perpetuity. This is, of course, a terrible outcome and it's projects like this one that are trying to change it.
So I applaud the effort and hope it catches on, become ubiquitous, and I can take the curl and wget snippets out of NV.
Re: HTTPie: A cURL-like tool for humans
#35Earlier quoted context omitted.
Why not use JSON syntax for JSON instead of introducing your own, though?
You can still use regular JSON syntax, if you like: echo '{"foo": "bar"}' | http url The reason for having the simplified one is that it's less verbose and usually doesn't even require you to quote it: http url foo=bar
Re: HTTPie: A cURL-like tool for humans
#36Earlier quoted context omitted.
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 on…
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.
Re: HTTPie: A cURL-like tool for humans
#37"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'm not a huge fan of cURL, but most people who use cURL don't use the command line either. They use the cURL library and access that functionality through a high level language (PHP, C, C++, whatever).
Re: HTTPie: A cURL-like tool for humans
#38"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…
Rather than admit that even incremental usability improvements are not only useful, but continue to pay dividends long after the tool is produced, you lambast the author and the effort.
Not cool.
P.S. You should watch Bret Victor again, talking about how much easier it is to crush an idea than to support it and nurture it. http://vimeo.com/36579366
Re: HTTPie: A cURL-like tool for humans
#39Earlier quoted context omitted.
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 on…
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…
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.
Re: HTTPie: A cURL-like tool for humans
#40Earlier quoted context omitted.
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 on…
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…
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: