IMHO the most important reason for not doing so: queries are not made for that! Queries are queries, not routes. You should route with routes (completely unexpected), not with queries.
This does not highlight any practical or even realistic theoretical benefits of using routes over queries. Besides, it's called "path", not "route", and I don't know of anything in URI spec that would support your vision.
The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a
resource within the scope of the URI's scheme and naming authority
Id's just <a href="/assets/main.css"> with a leading slash. Again, that's what / is for.
This breaks if you need to re-deploy to a sub-directory.
I think that was exactly what early 2000s forum developers thought, but as they learnt soon it was a really bad idea.
The only reason I know of that it was bad idea in 2000s is because early search engines arbitrarily assigned different values to words in query strings. This has changed.
Path and route are synonyms (I might be confused because of my mother tongue) and I wanted to highlight that fact: you should use routes (paths) to route.
> and I don't know of anything in URI spec that would support your vision.
Your proposal "?article/123" seems very hierarchical to me. You even used path-like syntax and "routing via queries" sounds inherently hierarchical. You should use a path instead.
> This does not highlight any practical or even realistic theoretical benefits of using routes over queries.
Of course it doesn't if you strip the important part of my comment :P Quoting myself: "The difference between query and route actually means something to the software interacting with your site."
It's akin to inventing your own HTTP verb.
> This breaks if you need to re-deploy to a sub-directory.
Then you should use <base>. That's why it's there, so you don't have to jump through hoops.
Using queries for navigation is just as bad as the defunct habit of using hashbangs, which served a purpose when there was no alternative. The technology moved forward and we have better solutions.
Firstly, routing is not inherently hierarchical. It's a process of mapping pieces of URL to variables with the purpose of figuring out which action to call. So your argument that implies routing it inherently related to URL paths (by the virtue of their names) is invalid. It can and often does involve queries.
Secondly, if you ever tried to implement a web framework from scratch, you would quickly see that routing something like "?controller=blah&action=blah&id=123" is MUCH easier than dealing with virtual paths. Aside from relative URL issues in templates, you also need to deal with differences between real assets and everything else.
Thirdly, my proposal does not go contrary to rfc3986. "The query component contains non-hierarchical data" is not the same as "query component must not contain any hierarchical data". If it did, you could also argue that it's "wrong" to put an address int query string, because, hey, it's a hierarchy. (And again, routing is not inherently hierarchical.)
Fourthly, base tag doesn't deal with the original use case I described and is a PITA to maintain.
This does not highlight any practical or even realistic theoretical benefits of using routes over queries. Besides, it's called "path", not "route", and I don't know of anything in URI spec that would support your vision.
Id's just <a href="/assets/main.css"> with a leading slash. Again, that's what / is for.This breaks if you need to re-deploy to a sub-directory.
I think that was exactly what early 2000s forum developers thought, but as they learnt soon it was a really bad idea.
The only reason I know of that it was bad idea in 2000s is because early search engines arbitrarily assigned different values to words in query strings. This has changed.