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.