Whether we need this depends on some other architectural decisions. I'm writing this up so I can refer to it elsewhere.
Right now, defining both GET /abc/* and GET /abc/def is an error at startup because the route definitions overlap, and Dropshot would not know which to handler to call when a request matches both routes. There are a couple of ways we could break ties:
- Order of route registration
- Simple to implement (I think? we're already using
BTreeMap for the route nodes, so we know the insertion order) and to understand
- Too easy to accidentally mess up the logic by moving routes around
- Specificity of matching
- Request to
/abc/def goes to the exact match because it ranks higher than a wildcard match
- While the logic is hidden in the implementation, the idea of match specificity is pretty intuitive. You can only change matching logic by changing the route paths, which is less error-prone than changing it by shuffling things around. However, it has the similar problem that deleting a more specific route can cause a wildcard to start matching requests it didn't match before.
- A little more work to implement, but not too bad. something in here
- Example ranking algorithms
Whether we need this depends on some other architectural decisions. I'm writing this up so I can refer to it elsewhere.
Right now, defining both
GET /abc/*andGET /abc/defis an error at startup because the route definitions overlap, and Dropshot would not know which to handler to call when a request matches both routes. There are a couple of ways we could break ties:BTreeMapfor the route nodes, so we know the insertion order) and to understand/abc/defgoes to the exact match because it ranks higher than a wildcard match