3 ms·
As always, it depends. Arguably, http://example.com/users/dcurtis/profile http://example.com/users/dcurtis/profile is short, but not too short. If a website/ser
by gry 18y ago
As always, it depends. Arguably, http://example.com/users/dcurtis/profile http://example.com/users/dcurtis/profile is short, but not too short. If a website/service is centered around people, it makes _more_ sense. Else, the longer URLs seem to make more sense. http://www.amazon.com/wii http://www.amazon.com/wii is only as useful as someone knowing what the Wii is.
I wouldn't consider the users and profile namespaces a mistake. People get cute and it can create a large constraint how your architecture works. Also, URLs structures as such are often a result of some framework behind it. http://example.com/model/controller/view http://example.com/model/controller/view. It expedites development and managing code something fierce. Perhaps there is opportunity for a shortening widget within the MVC pattern. I need to think about it -- or let other smarter people than me think about it. :)
http://www.amazon.com/shamwow http://www.amazon.com/shamwow is invalid, along with the other permutations I tried. Amazon doesn't have core shortening service, it seems.
I think the issue is more around URLs which can be parsed by a human vs the proverbial querystring. A TinyURL solves technical problems and looks nicer which is 2/3 of the way there. The remainder makes sense to a person.
- dcurtis 18y agoYou can't use the excuse that "the software urges me to do it this way, so I'll make the user's experience suffer." As a developer of user-centric software, it is totally your responsibility to do al the hard work for the user. That includes the couple lines in your routes file to fix the /model/controller/view default. /users and /profile do not ever have extra information, except in extreme cases where you have /users and /aliens and /pants that your app is centralized around.
- jaaron 18y ago/users and /profile could easily have extra information. a GET /users could provide a list of all users. the /users/dcurtis might be the blog or home page, while /users/dcurtis/profile is specifically the person's profile. Having a hierarchical resource namespace makes plenty of sense in many contexts. If nothing else, it's more likely to be long lived because it makes URL redirection easier in the future if the system changes. When version 2 of the site software comes out, someone can easily redirect all the /profile urls to a legacy system or parse them into the new system. Whereas a flat namespace is much harder to migrate and keep constant. And besides, we shouldn't confuse the two issues of readable URLs and short alias URLs. Both have very legitimate uses.
- dcurtis 18y agoYou're right that /dcurtis could have different information. But I am talking about webapps that would return a 404 for http://example.com/users http://example.com/users . The vast majority of major apps do not use urls the way you described. Unless you absolutely positively have to have another extra layer of url hierarchy, and you can justify it extremely well, please don't. It's just a burden on the user when they go to share/copy/read it.
- whatusername 18y agoamazon.com/books worked for me.. Imagine the namespace collisions if every product that amazon sold could shorten like that. Categories break down nicely though.. eg wii, books, even garden
- whughes 18y agoAmazon.com/wii is not a reference to the Wii itself. The article's author got it wrong there, or at least fudged the truth slightly. It's a category on the Amazon site. Thus, amazon.com/books works (as someone else said), but shamwow doesn't. Shamwow isn't a category, after all. I assume they do have shortening for categories, and they just keep their structure consistent.