
HTTPie 0.9.6 - jkbr
https://github.com/jkbrzt/httpie/releases/tag/0.9.6
======
theonemind
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"
      }'

~~~
rdtsc
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...

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

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

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

------
eddieroger
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.

~~~
therein
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`.

~~~
eddieroger
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.

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

~~~
niftich
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.

------
emilsedgh
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`](http://foo`) works. Which is super convenient! Give it a
try!

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

~~~
xaduha
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

~~~
ta0967
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.

~~~
xaduha
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.

~~~
ta0967
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.

------
kennell
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.

------
eknkc
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.

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

~~~
rkowalick
curl | json_pp

~~~
ak217
curl | jq .

~~~
pandler
I use:

    
    
        curl | python -m json.tool

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

~~~
detaro
Needs extra dependencies on many python versions:
[https://github.com/jkbrzt/httpie#sni-server-name-
indication](https://github.com/jkbrzt/httpie#sni-server-name-indication)

~~~
xxdesmus
thank you!

------
tuananh
is there a GUI app wrapper for this?

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

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

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

------
johns
Frequently discussed here:
[https://hn.algolia.com/?query=httpie&sort=byPopularity&prefi...](https://hn.algolia.com/?query=httpie&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

~~~
guessmyname
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](https://twitter.com/jkbrzt)

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

~~~
pests
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.

