defaults to GET request
http google.com
http google.com user=65"user=65" is not valid JSON, unless you consider it a single JSON string literal.
HTTPie converts that into a JSON object.
Curl will send the data literally as you send it - if you want to send JSON, give it JSON as the body. If you want to send a "Form POST" quest, give it an encoded query string as the body.
If HTTPie detected that what you gave it was valid JSON, or whatever other media type, and used that to 'guess' the request Content-Type, that would be useful and smart.
But HTTPie not only mangles input, it mangles it in a way that is completely non obvious.
passing it "foo=bar" will send a JSON encoded object like `{"foo": "bar"}`.
passing it "foo=bar&baz=boo" will still send a JSON encoded object like `{"foo": "bar"}`.
So, it knows that ampersand is a field separator, but then promptly ignores all the content after it?
So, no. I call bullshit on "sane defaults" when it mangles data, and silently drops data it's given.
Touché sir, your argument has won the day. /s
After all, this is a discussion forum where regular humans can share their experiences. Not debate club.
echo '{"foo": "bar"}' | http :8000
It also doesn't make it easy to use, because eventually the magic will guess wrong and it will go from magically the right thing even though I passed garbage arguments to completely the wrong thing at the drop of a hat.
An example of a "sane default" where curl falls short might be to enable redirects by default, because that is usually what the user wants (and correct client behavior).
Please explain how a well-defined key-value convention is equitable to "incomplete" or "plain wrong" arguments.
In what way is any of this opaque when it's fully documented and quite easy to follow?: https://github.com/jakubroztocil/httpie#id16
Would Java developers see this and imagine you're passing values for a .properties file?
If you've never seen the tool before, you also wouldn't know how it works at all. Once you hit help for the first time (you know, to actually learn how to use it), knowing it defaults to JSON is pretty much a base truth.
It's entire value proposition seems to be stongly tied to JSON support (2nd highest feature in the pitch at the top).
This is like saying you'd forget jq takes JSON strings...
The first feature pitch is “user-friendly curl alternative with intuitive UI”.
That is probably the most user friendly difference they could make for working with JSON based APIs
The program switches around between HTTP methods, content types, query building, request serialization, etc, at every minor syntactic change to the command line arguments. The fact that a foo=bar implies that the request content type AND the accepted response content type will be set to application/json AND the foo=bar is POSTed as a JSON object isn't a "sane default."
That is not to say it can't be a useful utility. The quirky syntax for query parameters, JSON-serialized request body, etc, can be learned and is quite concise, so after the initial learning curve, it can be used very efficiently.
"Sane defaults" is false advertising, because it implies the least amount of surprise. This tool is the opposite. It is unintuitive but potentially very efficient once learned.
It's a JSON-centric tool made for people who work with APIs that use JSON in very compatible way, with JSON-centric defaults
Changing the accepted type matches behavior of Js HTTP libraries like `request`, where accept and request content types are set in unison by default.
This stuff is all sane defaults for the people who are usually in Postman firing off JSON data to APIs that all look very similar.
"Sane defaults" don't exist in a vacuum, writing (and escaping) properly formatted JSON is a pain (see jq and how the 2nd paragraph in how to even invoke it is dedicated to escaping)
The tool defaults to removing that pain point in a very easy to understand way.
This strikes me as the best of both worlds--you're seamlessly educating the user on what is happening and what they could have done instead.
I'm against dishonest advertising with loaded phrases like "sane defaults" (this term has its place, but it's not here) and "for humans" (this term is always a red flag) when the tool invents a load of unconventional, unintuitive syntax.
Author of the dishonest advertising here ;)
I don't think the fact that the tool introduces a mini language for crafting HTTP requests on the command line contradicts with the statement that the tool also provides what the author believes are sensible defaults (e.g., default to POST when sending data vs. GET when not, default to "prettifying" HTTP messages for human consumptions on the terminal vs. not touching them when the output is redirected, etc.).
"For humans" is meant to highlight the focus of this project on usability and interactive usage, as opposed to curl’s focus on feature-completeness across a number of protocols and non-interactive usage:
> curl is a tool to transfer data from or to a server, using one of the supported protocols (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP). The command is designed to work without user interaction. [1]
In 99% of cases httpie can assume that I'm making a POST request or a GET request with json or query params. Very rarely will I need to add custom headers, or change the Content-Type.
Yes I can explicitly define the JSON body, headers and method type every time. Or I can use a tool which uses ..... "sane defaults"