29 ms·
You 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
by dcurtis 18y ago
You 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.