6 ms·

I never understood why people are so hell-bent on advocating https://example.com/item/7536855 https://example.com/item/7536855 over https://example.com/item?id=

by gambler 13y ago

I never understood why people are so hell-bent on advocating https://example.com/item/7536855 https://example.com/item/7536855 over https://example.com/item?id=7536855 https://example.com/item?id=7536855, or even https://news.ycombinator.com/?item/7536855 https://news.ycombinator.com/?item/7536855 in human-readable websites. The last form is short, allows for the simpler routing and much easier linking on the backend as you don't have to do any magic to resolve relative URLs. That's a tangible benefit, and it can make some code and operations much simpler. (For example, you could add an alternative page called item2, and it would happily reuse all the resources of item just via relative URL resolution.) Ability to use direct links (<a href="?comment/111">) also means more readable templates and easier time finding what links where. The first form is supposedly "hierarchical" and "more semantic". What does that buy us in practical terms?

solipsism 13y ago
Most modern routing systems I've worked with can match against any of the URL schemes you describe, without any difference in flexibility. Segments of the path can be tied to hardcoded routes, or passed into handlers as parameters, or any combination thereof. And relatively URLs work just fine as "/comment/123". I'm not sure I understand what you mean by "direct link".
- gambler 13y ago
  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.
  - kaoD 13y ago
    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. Don't do that. Please.
    - gambler 13y ago
      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.
      - kaoD 13y ago
antocv 13y ago
Its easier to parse both for humans and for many libraries paths than queries.
frou_dh 13y ago
I'm not particularly advocating either, but I suspect a lot of us have a lingering notion of the latter part of a URL literally being a file path. Web development for beginners (used to?) consist of pooping handwritten html and image files into a directory that a webserver happened to know about. No dynamic stuff or indeed any programming involved.
nailer 13y ago
> For example, you could add an alternative page called item2, and it would happily reuse all the resources of item just via relative URL resolution. I don't understand. If you wanted, for some odd reason (you hate search engines?) for the same resource to have two URLs, you could simply do: app.get('/items/:itemID', itemController); app.get('/item2/:itemID', itemController); Though that seems like a very strange thing to want. > What does that buy us in practical terms? I can crawl it, and expect to find different resources at different URLs, like every other news website.

by gambler 13y ago

solipsism 13y ago

Most modern routing systems I've worked with can match against any of the URL schemes you describe, without any difference in flexibility. Segments of the path can be tied to hardcoded routes, or passed into handlers as parameters, or any combination thereof. And relatively URLs work just fine as "/comment/123". I'm not sure I understand what you mean by "direct link".

gambler 13y ago
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.
- kaoD 13y ago
  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. Don't do that. Please.
  - gambler 13y ago
    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.
    - kaoD 13y ago

antocv 13y ago

Its easier to parse both for humans and for many libraries paths than queries.

frou_dh 13y ago

I'm not particularly advocating either, but I suspect a lot of us have a lingering notion of the latter part of a URL literally being a file path. Web development for beginners (used to?) consist of pooping handwritten html and image files into a directory that a webserver happened to know about. No dynamic stuff or indeed any programming involved.

nailer 13y ago

> For example, you could add an alternative page called item2, and it would happily reuse all the resources of item just via relative URL resolution. I don't understand. If you wanted, for some odd reason (you hate search engines?) for the same resource to have two URLs, you could simply do: app.get('/items/:itemID', itemController); app.get('/item2/:itemID', itemController); Though that seems like a very strange thing to want. > What does that buy us in practical terms? I can crawl it, and expect to find different resources at different URLs, like every other news website.