I don't get how you think that second part is a "sane" default.

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

Completely agree. Opaque magic to "guess what you want" from incomplete or plain wrong arguments isn't "sane defaults."

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

> Opaque magic to "guess what you want" from incomplete or plain wrong arguments isn't "sane defaults."

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

Fairly sure I'd forget all the time that it thinks giving it a syntax that looks like form-encoded obviously means I want to send a JSON request.

key=value is a convention used in so many places that have nothing to do with form encoding

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

How many key/value formats commonly used for http request/response transactions use = ??

The first feature pitch is “user-friendly curl alternative with intuitive UI”.

I'll leave it at this, I'm glad they prioritized not having to escape JSON on the command line over people who have no idea about how the tool works being able to guess how to pass form inputs.

That is probably the most user friendly difference they could make for working with JSON based APIs

Right, but this is HTTP, which has used form encoding since... 1998, if RFC 2388 is to be believed.

That doesn’t sound right. I’m pretty sure it’s older than that. New RFCs tend to replace old ones and I don’t think they reliably make it painfully obvious this is what’s happening.

A URL without a scheme is somewhere between "plain wrong" and "incomplete."

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.

The third feature listed after "syntax" and "formatting" is "Built-in JSON support"

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.

Broadly curious, what would your thoughts be if the CLI printed it's guesses, alongside how they could be more explicit? "X is not valid, assuming: [more explicit version of argument goes here]"

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.

Just to be clear (see my other comment), I'm not against tools that require a learning curve.

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.

> 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]

[1] https://curl.haxx.se/docs/manpage.html

Sane defaults means it is making 99% of cases that I'm using the tool easier, convention over configuration.

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"

I think it's hard not to like the HTTPie interface if you give it a bit of time. The design is brilliant.

I gave specific examples where it's unintuitive and your response is "The design is brilliant".

Touché sir, your argument has won the day. /s

Charitably, the emphasis could be put on “if you give it a bit of time.” Read that way, it’s not an argument for intuitive UX, just a comment about how the UX grows on you. It doesn’t contradict what you said. Should it?

After all, this is a discussion forum where regular humans can share their experiences. Not debate club.

A design isn't "brilliant" just because "people got used to it, despite how shitty it is".

You can send it raw JSON too. For example:

echo '{"foo": "bar"}' | http :8000