HTTPie 0.9.6 | Hacker News Reader

HTTPie 0.9.6

github.com

108 pointsjkbr36 comments

I like how it allows you to abbreviate JSON, but the API I use most frequently puts objects within objects, and the readability rapidly goes down to "curl" level for this case. As far as I know, this is still as concisely as you can write this with httpie. Most of the things that don't involve putting an object in an object in json seem to write out much more cleanly in httpie. In this case, you still mostly end up just writing the json:

  http --json POST https://iad.servers.api.rackspacecloud.com/v2/123456/servers \
      'X-Auth-Token':'authtoken' \
      'Content-Type':'application/json' \
      server:='{
    "metadata": {
      "metadatagoes": "here"
    },
    "imageRef": "b21af3ef-1a1e-46b5-98ef-bb0c81b25292",
    "networks": [
      {
        "uuid": "00000000-0000-0000-0000-000000000000"
      },
      {
        "uuid": "11111111-1111-1111-1111-111111111111"
      }
    ],
    "flavorRef": "general1-1",
    "name": "servername",
    "OS-DCF:diskConfig": "MANUAL"
  }'

You know, I wonder (and perhaps this is already implemented and I just haven't heard of it) if that could be specified by auto-expanding paths:

server.metadata.metadatagoes+="here" server.imageRef+="..." server.networks+='[...]' ...

Yeah not sure about arrays...

Maybe that sort of stuff is best left to jq, and httpie could focus on interoperability with jq.

httpie can pipe data from stdin. So stuff like this might work?

   jq -n '.a.b.c = "x"' | http <url>

This feature is planned: https://github.com/jkbrzt/httpie/issues/78

That's awesome! Thanks

I like HTTPie and I use it from time to time, but I don't actually find the UI all that intuitive. It's probably just me, but having curl not actually care about the order of arguments makes it hard for me to flip back to HTTPie where it does actually matter. When I do, I usually expect headers to come first, since they actually do come first in a typical HTTP flow. But, again, it's probably just me, and maybe I need to force myself to use it more and it will become second nature.

Exactly my issue with it. I would make HTTPie my primary tool if its cli syntax was as lenient as curl's. It would save me piping my output to `jq`.

Reading the rest of this thread reminded me about piping to jq, which I forget as much as I forget to use HTTPie. Usually I'm checking headers and non-body stuff when I'm using these tools, but when I've got someone over my shoulder who's not as used to reading compressed JSON, or they're looking for something specific, it's nice to get a pretty format. I guess that's the biggest hurdle in just changing habits.

Great tool & deserves all the credit it gets, but this tool/thread comes up every X months.. what's up HN?

Presumably because it's really, really difficult to make old threads trend again, and if you comment on an old thread most people won't see your post.

A while back I was trying to craft a curl request and in middle of it i made a mistake and started the command with GET. And it worked! For a moment I thought its a Fish feature.

It turns out libwww-perl has commands named like HTTP methods installed in my /usr/bin.

So `GET http://foo` works. Which is super convenient! Give it a try!

edit: There's a high chance its already installed on your machine.

This tool has a really nice UI by which HTTPie is actually partly inspired. And it also includes `POST':

$ echo 'hello=world' | POST httpbin.org/post

Can also be solved with some aliases to curl

alias GET='curl -sk'

alias DELETE='curl -sk -X DELETE'

alias PUT='curl -sk -X PUT --data-binary @-'

alias POST='curl -sk -X POST --data-binary @-'

echo "hello" | POST localhost

probably doesn't need that -k flag, I was just using it to test HTTPS server with a self-signed certificate

do not use -X without having read the manual, it can break redirects and other things.

from the curl(1) manpage:

       -X, --request <command>

              (...)

              Normally you don't need this option. All sorts of GET, HEAD, POST and PUT requests  are  rather
              invoked by using dedicated command line options.

              This  option  only  changes the actual word used in the HTTP request, it does not alter the way
              curl behaves. So for example if you want to make a proper HEAD request, using -X HEAD will  not
              suffice. You need to use the -I, --head option.

              The  method  string you set with -X will be used for all requests, which if you for example use
              -L, --location may cause unintended  side-effects  when  curl  doesn't  change  request  method
              according to the HTTP 30x response codes - and similar.

PUT is indicated by using -T / --upload-file, POST by -d / --data or any --data-foo option (eg. --data-raw). DELETE is the only HTTP method in the parent list that needs -X to be used.

The point is to have the ability to pipe to curl, will -T / --upload-file allow that? For now I'm happy with how it worked.

the manpage is very explicit about that:

       Use the file name "-" (a single dash) to use stdin instead of a given file.
       Alternately, the file name "." (a single period) may be specified instead of
       "-" to use stdin in non-blocking mode to allow reading server output while
       stdin is being uploaded.

Been using it for a while now, highly recommended it!

The syntax and various options are super easy to learn, output formatting is great and it is overall a lot less clunky than curl for most stuff.

I use httpie a lot. Whenever I'm testing some http headers, an api call etc, it has become my go to tool. Brilliant piece of software.

If you haven't checked it yet, just give it a shot.

I really wish curl had a --pretty-json option.

curl "http://foo.com/some_json_endpoint" -H 'Accept: application/json' | python -m json.tool

curl | json_pp

curl | jq .

I use:

    curl | python -m json.tool

any plans to add support for SNI? seems you don't right now.

Needs extra dependencies on many python versions: https://github.com/jkbrzt/httpie#sni-server-name-indication

thank you!

is there a GUI app wrapper for this?

A GUI wrapper for a CLI wrapper, wrapper-ception :D

If you want a graphical interface for a HTTP debugging tool like this, I recommend you this tool [1] (only for Mac) or this [2]. I personally prefer Curl, after years using command line tools I got in love with the double dash sign to apply options to the program, and HTTPie unfortunately hides the options and forces you to write the command arguments in a semi-specific order, most people use HTTPie only for the colored output.

[1] https://paw.cloud/

[2] https://www.getpostman.com/

Not strictly a 'GUI' wrapper, but there are some interactive HTTP clients, which features like autocomplete:

[1] https://github.com/eliangcs/http-prompt, built on HTTPie

[2] https://github.com/cloudhead/http-console, on Node.js

Frequently discussed here: https://hn.algolia.com/?query=httpie&sort=byPopularity&prefi...

I think this was re-posted a 100th time because the author [1] released version 0.9.6 [2] like three hours ago. And to save you guys a click here is the list of (significant?) changes.

- Added Python 3 as a dependency for Homebrew installations to ensure some of the newer HTTP features work out of the box for macOS users (starting with HTTPie 0.9.4.).

- Added the ability to unset a request header with Header:, and send an empty value with Header;.

- Added --default-scheme <URL_SCHEME> to enable things like $ alias https='http --default-scheme=https.

- Added -I as a shortcut for --ignore-stdin.

- Added fish shell completion (located in extras/httpie-completion.fish in the Github repo).

- Updated requests to 2.10.0 so that SOCKS support can be added via pip install requests[socks].

- Changed the default JSON Accept header from application/json to application/json, /.

- Changed the pre-processing of request HTTP headers so that any leading and trailing whitespace is removed.

And please Mr. Roztočil stop posting your project here so frequently, there is a limited number of links in this website that get to the front page, and it is annoying to see duplicated content so often. If there is people unaware of your project by now, it is probably people that are not involved in anything related with HTTP debugging, and people that already know the project can easily go to GitHub and see the changelog by themselves, I certainly didn't understand why was this posted again after I started looking for a reason, then found that version 0.9.6 was released :-(

EDIT: Maybe I should blame the +40 accounts who upvoted this.

EDIT2: Re-organized paragraphs to display the changelog before my (irrelevant?) rant about the duplicated submission.

[1] https://twitter.com/jkbrzt

[2] https://github.com/jkbrzt/httpie/releases/tag/0.9.6

To be fair he didn't post the project itself in over 4 years. His other submissions related to this project links directly to a new release, which seems ok.

You're right that this submission was unnecessary as there's been plenty of recent general discussions about the project. It would have been better to post a link directly to the new release/changelog and indicate that in the title. That'd probably also lead to fewer upvotes as other HN users would know that this is a feature release, not a new project.

Thanks, we updated the link from the homepage.

The community obviously thought it was interesting despite being well known. Maybe today's users are not the same as the ones who saw it last week.

Reply on news.ycombinator.com