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.
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.
http://tools.ietf.org/rfc/rfc3986.txt section 3.4 the very first sentence says: "The query component contains non-hierarchical data"
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.