ServiceStack/ServiceStack — pull request #827 by kal (2013-09-11 15:14:19+00:00)
Title: Extended wildcard functionality

I wrote this because I wanted to be able to have wildcard elements in the middle of a path definition. This update allows you to use path definitions like `/{Slug}*/sparql` or `/data/{Slug*}/version/{Version}`. You can also have multiple wildcards in a path definition like `/{Slug*}/options/{Options*}`

The limitation is that if there is a path element immediately following a wildcard, it *must* be a literal (as the code uses this to tell when to stop matching the wildcard in a request path). Of course a wildcard can still appear at the end of a path definition where it simply matches the rest of the path.

One side-effect of this change is that the weighting of results ended up not working quite as I wanted as a wildcard was still only reducing the score by 100 regardless of how many parts of the request path it matched. So I changed the scoring so that wildcard reduce the score by 100 for each path element that they match. So when the path definition `/data/{Slug*}` matches `/data/wildcard/path/sparql` the score would be 710 (or 701), but the score for the path definition `/data/{Slug*}/sparql` would be 810 (or 801) - this makes the second pattern "more specific" and so preferred over the first.

As far as I can tell this change to the scoring is the only impact this change should have on existing users (because their route scoring would change if they are using wildcards). The only impacted class is ``RestPath``. I have also included unit tests in this pull request.

I hope you will consider including this in ServiceStack!

Cheers

Kal