In this world of "pretty urls" and a more RESTful web, everyone seems to agree that file extensions on the URL are bad as well as query string parameters. I very much agree. However, one of the subtilties that I find myself disagreeing with most on are the uses of trailing slashes.
According to A List Apart, (and who am I to disagree though here I am doing just that), all URLs should end with a trailing slash. I cannot say that I agree. I see their point from a browser to server relationship, but semantically for me, it doesn't make sense.
If I'm making a request for a resource, the "end of the line" so to speak is that resource:
http://www.somesite.com/show-me-something
In this example, I'm asking the server for what it has as a default response to "show-me-something" and my code should handle that just fine and deliver up that resource. If I want to see that same thing in xml, I would just modify the request like so:
http://www.somesite.com/show-me-something/xml
In this scenario, I'm requesting the xml representation of the "show-me-something" resource. My requested resource is the xml so there shouldn't be a need to have a trailing slash at the end.
To make a left-field comparison, I don't go to the grocery story to buy a can of beans only to go into the store, open that can of beans and pour them into my hand and go pay. I want that can of beans, and the end result is the same, but the can is part of the package. I get the whole thing. Requesting "/beans/" to me is like opening that can and getting just the beans (whats inside of the can), leaving the can on the shelf. Requesting "/beans" gives me the whole can. True in the end I'll be getting them out, but that's more like "/beans/pour" isn't it? I could be donating the can, "/beans/donate-to-food-pantry". Its sort of an "out there" kind of view, but it makes sense to me in my own little world.
Another reason i don't like the whole traling slash is for print ads. An end user reads a print add telling them to go to some url. Having that traling slash out there just doesn't look or feel right in print. It could also be misinterpreted by the end user and they're left asking themselves, "what comes next?" or "what am I actually requesting?"
I had quite a long conversation today with a colleague about this, and while neither of us could convince the other, I did concede that consistency would help and if he wanted everything to end in a trailing slash, that was fine with me as long as we could respond to both, because inevitably some end user will forget that slash and our application should be able to handle that.
Its easily handled, but to me, the slash is a separator that tells me, "there's more to come" or that I'm requesting "literally" a directory listing. If all I'm after is some "noun" -- a resource that is in and of itself a complete resource -- there should be no need for a trailing slash. Now if that resource has some extra options that can be requested, it would contain the slash but followed by whatever resource the user is after.
The no-slash rule is in effect here on sudovi.com but you'll notice it should respond to both, in my mind...this is the best way. Just handle both situations and there's no need to worry. My argument is purely semantics here and apparenlty I'm wrong ;)
I do feel it necessary to point out however, that even the article's url itslef violates that rule. It works if you use the traling slash or not, give it a try!
I'd love to hear some other opinions on this, though I'm assured its not a matter of opinion at all, just "that's the way its done."
Copyright 2008 -- all rights reserved