>
> .....
>
> Would it be possible for us to simply replace the semicolon with the +
>
> character?
Does anyone know of any technical obstacles to this approach? While I'm no
fan of constantly changing an api this seems to me to be the best solution
proposed so far.
Koz, any thoughts on whether '+' would solve the problems that ';' couldn't?
According to the standard encoding rules for URIs (and often applied
in front-end web servers or intermediary proxies), '+' would get
mapped to a space character ... likely not what you really wanted.
Of course, the initial Rails use of ';' for this was problematic as
well, since that character is reserved for delimiting the start of
path parameters (specific to a path element in between slashes, as
opposed to request parameters that come after a '?' character).
Personally, I think the current edge approach (using a '/') is the
best alternative with current browsers.
I'm a fan of the singular vs. plural thing. It makes sense to me and
while it's true that it doesn't hold up the "each level of the url
must be meaningful", very few apps do.
As for the uncountability thing, I wonder how many people actually use
uncountable names as resources. Also, the routing could force devs to
disambiguate when given an uncountable resource name.
At one time I would've agreed with you on this, but I've come to admire
the way rails URL's are "hackable" by default. That is, you can hack off
the end of the URL, and more often than not you're able to move to a
higher level of the hierarchy. I believe good websites and web apps
should have short, easy to read, hackable URLs.
Here's an article from Jakob Neilsen about how URLs are a strong part
of the user interface, and why it makes sense to pay attention to them:
URL as UI: URL as UI
I've heard all the standard REST arguments about URLs needing to be opaque,
but I do believe that some users (myself included) rely on them to be
"hackable". In fact I tend to directly manipulate the URL more than
clicking on links in breadcrumbs or other navigation on web pages.
At one time I would've agreed with you on this, but I've come to admire
the way rails URL's are "hackable" by default. That is, you can hack off
the end of the URL, and more often than not you're able to move to a
higher level of the hierarchy. I believe good websites and web apps
should have short, easy to read, hackable URLs.
Here's an article from Jakob Neilsen about how URLs are a strong part
of the user interface, and why it makes sense to pay attention to them:
URL as UI: URL as UI
I've heard all the standard REST arguments about URLs needing to be opaque,
but I do believe that some users (myself included) rely on them to be
"hackable". In fact I tend to directly manipulate the URL more than
clicking on links in breadcrumbs or other navigation on web pages.
Amen. URLs are *very* important... something that the Rails community embraced from the beginning, but now seems to have lost a bit in the pursuit of the RESTful golden hammer.
I break out of the typical Rails url-scheme at least a few times on every app I write. I choose URLs that will make sense to the user (or at least make sense to the stakeholder).
The semi-colon was always completely wrong and jarring to me (and caused difficulties with at least one stakeholder) and I for one danced a jig of jubilation on the news of its imminent demise.
Having URLs that are hackable are a good thing I definitely agree. I
believe just because a user hacks a URL then that URL has to exist per
se. A redirect to the plural version may be a sufficient fix.
/users/popular -> The popular users
/users -> A listing of all users
/user/1 -> User 1
/user -> 301 redirect to /users.
The only time someone would go to /user if they manually entered it
in. In this case the user ends up being happy because they get to
where they want to go.
Having the singular/plural distinction makes URLs more readable too.
/users/do_some_action
/user/adam/do_some_action
Its very clear whether its a member or collection action.
Sounds a little too tricky for my liking. What we really want is a
way for people to provide a prefix for their collection actions so
that we can distinguish these two cases
/users/the-prefix/popular
/users/mr-popular
I've used this before and it seems to make sense:
/users/all/popular
/users/mr-popular
cheers,
kampers
This seems to be really good solution. There is no need for edge cases
or tricky tricks and all you need is reserve one username (the same way
you’d reserve things like ‘root’, ‘admin’, etc.)
I raised this issue before in another forum when I discovered the switch from ; to / and got a response from David that it should be a non-issue. I didn’t really agree with that stance, but I do prefer the slash to semicolon overall for reasons similar to Ben.
The solution is to either include the id in your to_param slugs. Or to define your methods as reserved words that can’t be used in the attribute that generates these slugs. Personally I lean towards the former as the cleaner solution. Either way I don’t see that it warrants a core change. Out of the box there is no conflict, only when you introduce your own slugs is extra care required.
