Have an option to encode fields in URL (http://foo.com/q?x=1&y=2)

[tebeka]

Some services (like google maps api) require a GET with arguments encoded in the URL.
Add an option to do that (and probably default to it in GET method?)

[dair-targ]

Try this:
http 'http://httpbin.org/get?x=1&y=2'
URL with encoded parameters should be enclosed in either single ('..') or double ("..") quotes if you're using shell since unescaped & symbol is usually treated specially.

[tebeka]

I know I can hand craft the URL. However I prefer httpie to do that for me, and url-encode the parameters as well.
Meaning I'll run
http GET http://httpbin.org/get x=1 y='hello there'
And httpie will translate the URL to
http://httpbin.org/get?x=1&y=hello%20there

[dair-targ]

The items (link y='hello there') are used to form request body (which definitely may present in every request including GET). Also URL symbol escaping is supported by http. So the one and the only way is to encode URL arguments in URL and body arguments as items.

[jkbrzt]

On one hand, it would be good to keep the data parameter semantics consistent across all HTTP method (i.e., they are used to construct the request body no matter what the method is). There isn't almost any method-specific logic in httpie, which makes it possible to issue the same request via different HTTP methods simply by changing the method name argument.

On the other hand, although it's valid, it's rather unusual for GET requests to include a payload, but they often do contain URL parameters so it might be pragmatic to change it as tebeka proposes.

I'm not sure, though, if the pros (the ability to conveniently craft URL parameters) actually outweigh the cons (at the expense of breaking consistency).

[tebeka]

You can make it explicit with a command line switch if you prefer to avoid "magic" (--args-in-url? I don't not, I stink at naming things :).

[jakebasile]

I have run into this issue as well, and I think that @tebeka has a good compromise solution. http ---queryparams get http://www.google.com/ q=donuts would actually resolve to "http://www.google.com/?q=donuts", while the same command without the --queryparams flag would just work as it already does.

I would be willing to hack this out, but I wanted to get a feel for if the change is wanted or not. Thoughts?

[jkbrzt]

Another option would be to introduce a new separator for the querystring parameters. Perhaps something like name=:value.

It has the advantage that it's usable with any HTTP method and the existing interface remains unchanged. On the other hand, it's not as clean and intuitive as plain name=value would be.

[jakebasile]

I think name=:value ends up being better overall for the sole reason of not breaking existing conventions. I also like that it works on any method out of the box. It seems odd to use a query string anywhere but GET, but who knows? It doesn't hurt much to leave the option open.

[benatkin]

-q foo=bar is IMHO the best thing that I can come up with. Adding any more symbols would make things confusing, so I think it's best to pick the most closely related notation. I don't think it should make ordering significant or pick up more than one following argument. So -q page=2 -q rpp=20 would be the way to get page=2&rpp=20.

The best thing about this feature for me would be the ability to write options when I think of them, without going back to insert them.

[jkbrzt]

@benatkin That looks better than having a flag changing the meaning of name=value. The things is, however, that the params should intuitively go after the URL (like the rest of the key-value pairs that become part of the actual request), but all flags are expected to be at the beginning of the command.

I've merged @jakebasile's pull request (thanks!). Let's see how this feels, it can be changed before 0.2.6 final if it proves to be confusing or difficult to use.

[jkbrzt]

The format in 0.2.6 is name==value.

[tebeka]

Great, thanks!

[jakebasile]

Glad it made it (in slightly altered form) into the release! 🍰