Better API for matching query params

[chrisk]

Right now, the query params of the incoming request are sorted by key before we try to match against all the registered Regexps and URI objects. This works fine for URIs, because we can sort those query params too, so the user doesn't even know.

For Regexps, though, it seems impossible to figure out what part of the Regexp represents the query params and sort it; so the user has to be aware that their Regexp must be written to match against sorted params. That can be kind of hard sometimes. For example, a registration might look something like:

/example\.com\?[z\d]{2}=1&(opt1=a|opt2=b)$/

To match this URI:

http://example.com?9z=1&opt2=b

But also this URI:

http://example.com?zz=1&opt1=a

So you can see that if we sorted the second URI's params by key, it wouldn't match the Regexp. Instead, the user would have to register a Regexp that matches either order (or do two register_uri calls), which is pretty ugly.

We tried getting around this by calculating all the possible orders of the params and matching them, but that's O(n!) and therefore intractable for even pretty reasonable query params counts.

So the idea is that we could add a new API entirely, and get the query params out of the Regexp. Maybe an additional argument to register_uri with a hash of params that must in the request?

(Forked from issue #5.)

[akahn]

I think a new API, and no longer matching query params with Regexp is a good idea. A hash of params (as mentioned by mbleigh in #5) would be ideal.