1) If I hit Ctrl-D - it says "* Type qui[t] to quit."
If you know what I want to do, DO IT.. don't argue with me. Why would you write special extra code that specifically recognizes what the user wants to do and then tell them to do it another way?
2) putting a character in [X] usually means X is the character to hit. The help text is difficult to parse compared to what's normal....
Oh - I like the tool BTW - very handy otherwise.....
1) Agreed, that is a bit annoying, but I thought it less annoying than losing your entire session by quitting if you inadvertently type Ctrl-D twice to terminate input to the ‘body-set’ command.
2) The brackets are used similarly to their meaning in EBNF to denote optional elements. The expression ‘r[euse]’ means you can type ‘r’, ‘re’, ‘reu’, or ‘reus’ as aliases for the ‘reuse’ command.
> Response codes between 500 and 599 appear flashing black on yellow to indicate a server error
Note that flashing stuff is one of the major sins of UI design, on websites as well as console applications. Even on really serious errors, flashing text is just distracting and makes the oh so important information hard to read.
I strongly recommend to remove the blinking.
Instead, you could rethink the color scheme. However, the current colors are working quite well for me, so I guess that simply removing the flashing will already do the trick.
I used blinking text not so much in the “Danger, Will Robinson!” sense but rather to suggest that the response is not idempotent. Repeating the same request could result in a different, non-error response.
Holy crap, yes please! I literally need an interactive HTTP client like this RIGHT NOW. Thanks!
I've been dealing with a really hairy, picky quasi-RESTful API in Objective C, and it can be extremely hard to differentiate between a bug in my code and a bug in the API at times. Having an interactive console like this is going to save me a huge amount of time and hassle. Thank you so much for writing this!
Glad you like it. Please let me know if htty ends up causing you pain in the course of your API work. Either tweet me @get_htty or @njonsson or enter a bug or wish-list item at http://github.com/htty/htty/issues.
The aim of the project was to make htty an incremental advance over curl by layering aspects of a browser UX on top of it. What you get with htty that curl doesn't give you is primarily a session, and consequently a history. The other features are icing on the cake.
In the near future, the difference will be more striking. The ability to parse and build requests on various media types will make htty even better at the tasks of both API exploration and HTML screen-scraping.
definitely a cool project. Cool to experiment with UX on top of http. I guess the thing that rubbed me the wrong way initially is I really like seeing request / response. As a developer I learn alot from watching those; and anytime I have bugs in my http it's typically a header problem, so I like seeing those front and center.
1) If I hit Ctrl-D - it says "* Type qui[t] to quit."
If you know what I want to do, DO IT.. don't argue with me. Why would you write special extra code that specifically recognizes what the user wants to do and then tell them to do it another way?
2) putting a character in [X] usually means X is the character to hit. The help text is difficult to parse compared to what's normal....
Oh - I like the tool BTW - very handy otherwise.....