Implement EndpointSelector and MatcherPolicy
This change makes the EndpointSelector API more concrete, and is the
beggining of removing EndpointConstraint by making it obsolete.
To that end, I'm introducing MatcherPolicy, which is a
feature-collection API for registering policies that interact with the
DfaMatcher. The two policies that we'll need to start are:
- ability to order endpoints
- ability to append 'policy' nodes to the graph
These two concepts together replace EndpointConstraint. Extending our
graph representation is a really efficient way to processing most common
scenarios.
---
In general this helps with common cases where 4 or so endpoints match
the URL, but with different HTTP methods supported on each. Today we
have to process route values and call into some 'policy' to make a
decision about which one is the winner. This change pushes this
knowledge down into the graph so that it's roughly as cheap as a
dictionary lookup, and can be done allocation-free.
The big savings here is ability to remove more candidates *before*
collecting route data.
---
Along with this change, I also built 'rejection' into the DFA node
model, you can see an example with the HTTP Method handling that I
implemented. I implemented a policy that can treat failure to resolve an
HTTP method as a 405 response by returning a failure endpoint. This is
at the heart of much of the feedback we've gotten in this area around
versioning and http method handling. We also have a version of this
feature in MVC for [Consumes].
For preview one the branding is:
new thing = UseGlobalRouting/UseEndpoint
old thing = UseRouter
We're going to drop the name Dispatcher everywhere and make sure that we
position our new work as 'new and improved routing' instead of
introducing a new product/concept name.
We're not totally sure of the term Global yet, but it's what we're doing
for preview 1. Suggestions welcome for dicussion after we do the first
preview :)
Add benchmarks that include some HTTP method matching.
Clean up names and name like-kinded benchmarks alphabetically.
Matcher*Benchmark -> E2E including HTTP method selection
MatcherSelectCandidates*Benchmark -> Focused on just URL path processing
* Introduce RoutePattern
Introduces RoutePattern - a new parser and representation for routing
templates, defaults, and constraints.
This is a new representation for all of the 'inputs' to routing that is
immutable and captures 'out of line' information for defaults and
constraints.
This will allow us to unify the handling of constraints and values from
attribute style routes and conventional style routes.
This is a code dump of existing tests for TemplateMatcher and TreeRouter
converted to the format of matcher conformance tests.
Note that most of the new tests aren't yet supported by our experimental
matchers, which don't support many of these advanced features.
The instruction matcher was missing a few details, which made it faster
than it should have been. Right now I'm trying to keep the design of
these in sync. Once I fixed that it exposed a legitimate bug that was
blocking the github benchmark.
This change improves this area a bit by consolidating the matcher
implementations between the benchmarks project and the conformance
tests.
Additionally I split the minimal matcher into a really trivial
implementation for the simple tests and a more complex one for the
larger tests. This allows us to keep the plaintext/techempower scenario
in sight while also having a good baseline for the more sophisticated
tests.
Also starting to add tests that verify that matchers behave as expected.
The matchers now successfully execute all of these benchmarks, which
means that they support literals and parameters.
Missing features:
- complex segments
- catchall
- default values
- optional parameters
- constraints
- complex segments with file extensions
This is a good place to iterate a bit more of perf and try to make a
decision about what we want to implement.
Kiran Challa
Ryan Nowak
James Newton-King
Kiran Challa
Nate McMaster
Ryan Nowak