Comment by danpalmer | Hacker News Reader

Comment by danpalmer | Hacker News Reader

Parent Full thread

The `/foo/bar` and `/foo/*` use-case, where you want the first to go to a special page and the latter to go to some regular page. Perhaps the former is hard-coded/static and the latter looks up some URL parameter in a database.

You can of course always implement this within `/foo/*`, but then you're implementing your own URL routing and working around the framework rather than working inside the framework.

This feels to me like it's a change designed for APIs, not a change designed for user-facing websites. For APIs URL structure is often well defined in a technical sense, and this sort of use-case is rare. For a user-facing site however there are UX concerns, marketing concerns, SEO concerns, all sorts of reasons why some lovely, technically correct REST-style URL structure just won't work in practice. Unfortunately I know this from experience.

This work, the panic is only triggered when the precedence rules can't fix a conflict.

The behaviour documented here is actually extremely sensible and is best practices for anyone calling themselves a software engineer. Fail as early as possible, with as clear a message as possible.

But there is a precedence to pick for the panic case too.

I'm pretty sure that example worked even before the recent changes. From the documentation:

> Longer patterns take precedence over shorter ones, so that if there are handlers registered for both "/images/" and "/images/thumbnails/", the latter handler will be called for paths beginning with "/images/thumbnails/" and the former will receive requests for any other paths in the "/images/" subtree.

The two routes `/foo/bar` and `/foo/*` are not ambiguous and would be allowed by the router

Are they? It seems that the latter matches the former. i.e. for the path `/foo/bar` there are 2 matching routes. One must take precedence, but this router doesn't appear to allow that.

This may just be a syntax thing, I was being loose with syntax, and meant that the `*` would match anything for the purposes of this example.

It does allow that, the one without wildcards is more specific so it'll pick that one

This pattern already works and would work with this change, you'd just need to define `/foo/bar` first.

I understood what you were saying but it might be easier to read if you escaped the * characters.

Ha! Whoops! Thanks

Reply on news.ycombinator.com