Should resolution of route parameters be a requirement to match a route?

[bchubb-web]

given the route declarations:

Route::get('/{blog:slug}', [BlogController::class, 'show']);

Route::get('/{product:name}', [ProductsController::class, 'pdp']);

and go to /foo, it will match the blog controller, try to find a blog model instance with slug 'foo', and 404 if it doesn't exist.

IMO what SHOULD happen, is the parameter resolution happen as part of determining if the route matches or not, so if no blog post is found, it will search for a product with name 'foo', if it finds one match that route, if not keep checking routes.

this functionality could be triggered with a ->continueIfMissing() method on the route declaration, allowing it to be opt in as to not break existing sites.

[henzeb]

My suggestion is to go with the /blog/{blog:slug} and /product/{product:name} routes. I think that determine the route based on the existence of either one leads to slow pages if done for more than two...

Another implication is the 404 page to show when neither exists. do you show the blog 404 or the product 404?

[bchubb-web]

I do agree in most cases prefixing a route is the best way to go, i raised this due to a client requirement at work, that we are currently using a fallback route for.

For the 404, thats why i think a setting on the definition should be the way to go, so it is opt in behaviour when matching that route.

Route::get('/{blog:slug}', [BlogController::class, 'show'])->continueIfMissing(true);

Route::get('/{product:name}', [ProductsController::class, 'pdp']);

in the case that there is neither of each that would match, we could pass the blog route but then match the product route and handle the 404 there

Im not saying this is functionality that SHOULD be used, but that it should be possible IMO

[mbabker]

Personally, I'd make my own catch-all controller and handle the parameter resolution myself at that point. Resolving route parameters is an implementation detail of the framework IMO (it's already determined the route is matched and is now resolving the controller to handle that match), not something that should affect the behavior of matching routes. This really should be more of an edge case than a common enough requirement for frameworks to need to support this behavior in the router (and I say this as someone who's written a content integration for clients where we ultimately had a GET /* controller that matched everything to support their dynamic top-level paths at the expense of losing the framework's "no route found" support).