Add MatchUri method.

[cherba]

As shown in an example here, it would be nice given uri template to match a fully expanded uri. For example given uri template

http://localhost/weather/{state}/{city}?forecast={day}

and

http://localhost/weather/Washington/Redmond?forecast=today

to get back a dictionary

{
    'state': 'Washington',
    'city': 'Redmond',
    'day': 'today',
}

[sigmavirus24]

This is what we were chatting about in #6. The thing is this will only be easy-ish for the simplest cases of URI Templates. If you have the copyright ability to contribute an algorithm to do the matching, we'd happily accept it. We'd likely want an object that takes a URITemplate and can perform matches repeatedly (like how a URITemplate object can perform multiple expansions). Something like:

from uritemplate import Matcher, URITemplate

uri = URITemplate('http://localhost/weather/{state}/{city}?forecast={day}')
matcher = Matcher(template=uri)
matcher.match('http://localhost/weather/Washington/Redmond?forecast=today')

[sigmavirus24]

So based off of Section 1.4 (which I just reread today) it would seem that this would be more plausible if the Matcher were also aware of what the possible values would be. As in the above example something like:

matcher = Matcher(
    template=uri,
    state=AllowedValuesSet(
        'Washington', 'California', 'Oregon',
        ...
    ),
    city=AllowedValuesSet(
        ...
    ),
    forecast=AllowedValuesSet('today', 'yesterday', 'tomorrow'),
)

Or maybe have a separate object that maps the substitution names in the template to the allowed values?

[metatoaster]

I currently have implemented a urimatch submodule in a package I am currently building, which needs a generic uri router based on uritemplates. This test case covers some standard test case overall, which tests the expected results and also that the destructured mapping can be applied back to the template to reform the exact incoming uri. At this stage the package at hand is only just beginning and it intends to cover a large assortment of use cases, and currently there are limitations that I am not sure how to practically overcome (e.g. templates with same variable used multiple locations (/{foo}/{foo}), different query expansions that essentially do the same thing for certain values (/foo?{bar*} vs /foo{?bar*}), since my target use case is for routing - query strings are typically swallowed anyway, reserved expansions having the potential being too greedy, my personal hesitation for usage of out-of-band information for the type of the value).

Anyway, I think I only will be implementing a subset of what may be supported, and so what has been implemented are just some ideas that could be used for the uritemplate package in the event that a matcher is to be provided.