With enough code you can parse anything. My point is that query-based linking can greatly simplify your overall codebase and let the standard URL resolution in the browser do most of the work for you.
Let's look at two examples: example.com/?article/123 vs example.com/article/123.
In the first case you can link to example.com/assets/main.css by simply using <a href="assets/main.css">. It will work with no additional code. It will work from the root of the website, from ?article/123, or ?article/456, or ?any/other/place/you/want.
In the second case you need to reverse your routing logic, because "<a href="../assets/main.css">" will work on some pages, but will break on paths with more nesting (such as example.com/articles/about_it/123).
In ASP.NET MVC, for example, linking looks like <a href="@Url.Content("~assets/main.css")">. They've added a shorthand for it in Razor 2, but that means that the overall codebase is even more complex: your templating engine parses the content of your templates, find things that look like virtual URLs, reads the routing table, performs reverse relative resolution, and spits out the altered URL. It is extremely difficult to debug if something goes wrong. Is all this complexity really warranted?
If you're using PHP/Apache, query strings have an additional benefit of not needing any routing setting in .htaccess. Makes deployments somewhat more straightforward.
Also, you can easily implement "areas" with different assets by creating an actual sub-directory with an alternate index script, then copying and editing assets. This is way, way easier and more maintainable than all of the dynamic solutions I've seen.
"Wait", some people say, "but what if you change stuff?" If you change something on the backend, you change your routing tables to match it, so the external URLs stay the same. Yes, you still need routing. But now it only does one thing. You've decoupled routing from other components and made templates much simpler and more readable.
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. The difference between query and route actually means something to the software interacting with your site.
I only hate one thing more that using queries where you should use routes: using routes where you should use queries (especially common in shady SEO stuff).
> query-based linking can greatly simplify your overall codebase and let the standard URL resolution in the browser do most of the work for you.
It does not simplify my overall codebase at all. In fact, query routing will add lots of unnecesary code to my codebase if I have to parse the query as a route, while the route is already parsed as a route.
> In the second case you need to reverse your routing logic
Id's just <a href="/assets/main.css"> with a leading slash. Again, that's what / is for.
> If you're using PHP/Apache, query strings have an additional benefit of not needing any routing setting in .htaccess.
I think that was exactly what early 2000s forum developers thought, but as they learnt soon it was a really bad idea.
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.
Let's look at two examples: example.com/?article/123 vs example.com/article/123.
In the first case you can link to example.com/assets/main.css by simply using <a href="assets/main.css">. It will work with no additional code. It will work from the root of the website, from ?article/123, or ?article/456, or ?any/other/place/you/want.
In the second case you need to reverse your routing logic, because "<a href="../assets/main.css">" will work on some pages, but will break on paths with more nesting (such as example.com/articles/about_it/123).
In ASP.NET MVC, for example, linking looks like <a href="@Url.Content("~assets/main.css")">. They've added a shorthand for it in Razor 2, but that means that the overall codebase is even more complex: your templating engine parses the content of your templates, find things that look like virtual URLs, reads the routing table, performs reverse relative resolution, and spits out the altered URL. It is extremely difficult to debug if something goes wrong. Is all this complexity really warranted?
If you're using PHP/Apache, query strings have an additional benefit of not needing any routing setting in .htaccess. Makes deployments somewhat more straightforward.
Also, you can easily implement "areas" with different assets by creating an actual sub-directory with an alternate index script, then copying and editing assets. This is way, way easier and more maintainable than all of the dynamic solutions I've seen.
"Wait", some people say, "but what if you change stuff?" If you change something on the backend, you change your routing tables to match it, so the external URLs stay the same. Yes, you still need routing. But now it only does one thing. You've decoupled routing from other components and made templates much simpler and more readable.