You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Enhance endpoint selection by resolving ambiguities through constraint specificity analysis
Reduce ambiguity between constraints by defining a level of specificity between the constraints.
Previously, if you had two endpoints as follows:
```
GET test/{id:required}
```
and
```
GET test/{id:guid:required}
```
The DefaultEndpointSelector would not be able to determine which endpoint is the correct
one among the two, as neither violates the Route Constraint policy and therefore are
considered valid candidates. From a human perspective, the endpoint that has the constraint
of the GUID is more specific than simply REQUIRED, but the engine did not make that
distinction. Now, the DefaultEndpointSelector can eliminate ambiguities based on their
constraint level of priority.
Lets say the same routes described above. The engine will get two candidates available for it,
but it can remove the first one cause its less specific than second one. But it is interesting
to note that if the system cannot determine the priority, it will still report the ambiguity.
Let's assume that the second request was equal to the first, it would trigger AmbiguousMatchException.
The currently specifity order is defined as (from higher to lower one):
1 - Strong typed route constraint (e.g int, guid, long etc.)
2 - Ranged route contraint (e.g min, max, range)
3 - Length route constraint (e.g length, minlength, maxlength)
4 - String patterns (e.g regex, alphanumerical)
5 - File and non file
6 - Unknown route constraint
7 - Required route constraint
As mentioned earlier, if after processing the ambiguities he still hasn't been able to
determine a specificity, he will report the ambiguity, since there is nothing to be
done in this case : ).
0 commit comments