URL params should auto-encode/decode

[JamesDunne]

It's not clear to me whether URL params are automatically URI encoded or not here.

When I open the URL params (or when I edit the raw request URL) it should automatically decode URL params. I should be able to edit these as normal and the request URL field should automatically update with the encoded values.

This is tricky, I know, because there are multiple variants of URL encodings for parameters. So perhaps a drop-down to select the standard would be best, e.g. some prefer '+' yet others prefer '%20'.

Regardless, I shouldn't have to be typing out encoding sequences myself. It gets to be a pain to try to remember which characters are URL-unfriendly and need to be encoded.

[a85]

Hmm. URL params are automatically urlencoded at the time of OAuth generation and request sending. Switching between the encoded and the unencoded parts is tricky because you won't know what exactly you are editing. Also Postman won't know whether you are writing something which is already urlencoded.

[JamesDunne]

I think to solve this you can introduce a few simple rules. Namely, the URL text box should always validate as a URL. OAuth generation should just chop off the query string from the encoded URL and use that; no problem there. If one wants to edit encoded parameters, he should edit the raw URL and type in those encodings complete with the ? and & and %6F characters. Once a URL validates, it updates the URL params table with decoded values. Use the URL params table to edit the decoded values, and those should be automatically URI-encoded back into the URL text box.

Advanced REST Client does it in a less restrictive way than this proposal by letting the user decide when to encode/decode with "encode all params" and "decode all params" buttons.

The way I normally work in ARC is to paste in a properly encoded URL into the text box, then open its params editor and decode all, edit/add what I wish, re-encode all, and send that request. I'd prefer a REST client to give me a sane way of handling URL param editing, since that's the majority of the work that I'm doing in the REST client. I have a feeling that wanting to edit query-string params in their encoded state is the exceptional case.

[JamesDunne]

Now that I've started using the environments and tokens, things get slightly more complicated here. Also, there's the trouble of having certain encoded characters that can't easily be represented in a raw form in a text box, e.g. %00.

[a85]

I saw the ARC implementation and that I think is one way to do it. Advantage of not having the URL as fully encoded is that I can just work with the URL text field, make changes and fire a request. I believe this is what a lot of people would use in their workflow.
As you mentioned, there is the added issue of environments and tokens too so the URL can not be validated as a proper one in any way. Then there is another pending proposal where you can select parts of a URL to be configurable. For example /users/:user_id/. With this the ":user_id" part becomes an editable param the same way as GET params.
Maybe I can add a shortcut key to display the final URL which is going to be sent taking all factors into account. You can toggle it on/off to see what will be sent.

[a85]

Will be implementing this as part of #85 and #81. Encoding will be taken care of automatically for now.