Allow default resty options

[Brandon Beck]

I'd really like the ability to specify default resty options. I'm lazy and in certain cases I would like to always be able to type URLs in the same way that I specify them in my browser. For example I'd like the following scenario to work:

$ resty http://localhost:8080
resty http://localhost:8080*

$ # This won't actually work...
$ GET '/jane?rev=1'
<some error from the server>

$ # Instead you need to do...
$ GET '/jane?rev=1' -Q
{ "_id": "jane", "active": "true", ... }

$ # Or you can do...
$ GET '/jane' -q 'rev=1'
{ "_id": "jane", "active": "true", ... }

Ideally you'd be able to tell resty when you specify the URI base (or perhaps through a configuration file in ~/.resty) that you want all GET commands to include resty's -Q option. I'm not quite sure what the syntax should be for that though. I'd be perfectly happy if it was buried inside of a config file somewhere and not available to be set via the command line during the URI base specification.

Think it's reasonable to add something like this?

[Micha Niskin]

Have you looked at the Per-Host/Per-Method Curl Configuration Files section of the docs? I think that would do what you want...

Also, any options you specify on the command line when you call resty itself are saved, so for instance:

~$ resty www.example.com -Q
http://www.example.com*
~$ GET /jane?rev=1    # makes a GET request with -Q resty option

[Brandon Beck]

Does it do what I want? My understanding from looking at the resty source code is that it's resty doing the url encoding not curl. It's the handling of the -Q option which seems to execute something like:

[ -z "$quote" ] && _path=$(echo "$_path"|sed 's/%/%25/g;s/\[/%5B/g;s/\]/%5D/g;s/|/%7C/g;s/\$/%24/g;s/&/%26/g;s/+/%2B/g;s/,/%2C/g;s/:/%3A/g;s/;/%3B/g;s/=/%3D/g;s/?/%3F/g;s/@/%40/g;s/ /%20/g;s/#/%23/g;s/{/%7B/g;s/}/%7D/g;s/\\/%5C/g;s/\^/%5E/g;s/~/%7E/g;s/`/%60/g')

[Micha Niskin]

I'd like to have an intuitive way to set default arguments on the fly, but i'm not exactly sure how to do it. One way would be to allow something like:

~$ resty -q rev=1

where resty would know that -q is not a valid hostname and instead set those arguments for the rest of the session. But what would you do when you want to remove an argument? What about multiple arguments, like -H 'accept: foo' -H 'content-type: bar'?

[Micha Niskin]

No, you're right, you do need the -Q option, but I was pointing out the config files you can use to specify default resty options, including -Q.

[Brandon Beck]

My $0.02 says that if you run the resty command you're reconfiguring resty to operate differently. You already have that paradigm today with the way everyone uses it.

~$ resty 'http://localhost:8080'
http://localhost:8080*

~$ GET /jane
<fetches http://localhost:8080/jane>

~$ resty 'http://localhost:8081'
http://localhost:8081*  # Just lost the binding to localhost:8080

So why not follow the same paradigm with resty options?

~$ resty -Q 'http://localhost:8080'
http://localhost:8080* -Q

~$ GET '/people?name=jane'   # makes a GET request to http://localhost:8080/people?name=jane (no quoting)
...

~$ resty 'http://localhost:8080'
http://localhost:8080*

~$ GET '/people?name=jane'   # makes a GET request to http://localhost:8080/people%3Fname%3Djane (with quoting)
<likely error>

[Brandon Beck]

Wait, I can specify -Q in a configuration file that resty will read? Which configuration file is that? I don't see any of that in the resty code.

[Micha Niskin]

Yes. There are two ways to specify default options. The first way is to specify them on the command line when you call resty itself, like this:

~$ resty http://example.com -Q

This sets the -Q option for all requests for the rest of the session.

The other way is with a config file. For this example you'd create a file ~/.resty/example.com with the following contents:

GET -Q
POST -Q
PUT -Q
DELETE -Q
HEAD -Q
OPTIONS -Q

This would add the -Q option to all GET, POST, PUT, DELETE, etc. requests to the example.com domain.

[Micha Niskin]

Oh, dang. It's not doing what I thought it was doing. I'll make it work correctly now :)

[Brandon Beck]

It's not working how you thought it was because resty is passing those options to curl right? How are you going to distinguish between resty options and curl options especially considering some of them overlap (-Q for example)?

One possibility could be to allow resty options before the base URI and curl options after the base URI (like they currently must be). It definitely isn't ideal, but I don't know of a better way.

[Micha Niskin]

I chose -Q because it's not an option you'd use in curl if you're doing http stuff, so there really isn't overlap there. The weird part about it is that resty will correctly memoize curl options, but not resty options. This is because of the ad-hoc way it handles the command line options. I didn't want to use getopt there because that would mean adding in the curl optstring, basically. I didn't want to make it that rigid. I think I can make it work though, if the persistent options are passed to the resty command.

[Brandon Beck]

Gotcha, makes total sense to me. I look forward to getting to use it. :)

[Brandon Beck]

Hi Micha, was just wondering if you've had any time have a look at this anymore? Is there some way I can help you?

[Micha Niskin]

Sorry, I've been holding my nose to the grindstone lately with deadlines and whatnot. If you have any suggestions I'd be happy to merge your changes in, otherwise I'll try to work something out next week.

[Adrien Becchis]

Has been implemented in a similar via than host defined options via the resty special host :)

[Adrien Becchis]

3.0 is gonna land soon, closing the issue