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."

~
:wq!

Well said. Trailing slashes are useless in print and in spoken conversation (slash dot dot org SLASH!). You should always code for and demand both, as well as something like example.com?hello because it's a cleaner user interface. The trailing slash is "machine talk" and should be triple checked by the web server anyway (because only the file server is going to know if that's a file or a directory). It is true that every browser, server, sitemap, search engine, and rewriter handle things differently, but in the end the trailing slash is a useless visual aid .... (and so are most file extensions).

A web service API is also a human user interface as well as a computer interface so I would want a restful API designer to be mindful of this issue as well.
~
:wq!

I should have read that article FIRST !

I would agree that it is friendlier to your server to include a trailing slash in coded anchor links ... but I still might go with a cleaner look anyway for consistency. Plus, in the future if you switch to another platform that URL could be a directory OR a script OR something rewritten. There's no way for you to know that now.
~
:wq!

@Scott -- Its good to know I'm not crazy then. As far as that article goes, it talks about actual "seconds" delay in your server figuring out whether you're requesting a file or a directory, etc. SECONDS?!?...I don't think so. We're talking micro-seconds here to figure that out even in shared hosting environments. I do agree though, it is lighter on the server to include the slash. As far as changing platforms messing things up, I think thats pretty much a fallacy as well. If you've thought things out well enough, you shouldn't have ambiguous names etc and directory names matching actual file names. I'm always careful not to do such things. Perhaps I'm helped out a bit by whichever framework I am using but I've not run into this problem anywhere as of yet. Thanks for stopping by.
~
:wq!

Don't confuse the way humans use URLs and the way machines use URLs. Humans can intuit shortcuts. Machines (at least at the level we're discussing) can only follow rules.

You should always set up your web server so that the slash is optional, but added when needed by the web server to determine the requested resource (like directory indexes in Apache).

The resource returned by the web server should be unambiguously the default rendering of the resource if the slash is missing or present with nothing following a trailing slash.
~
:wq!

[b]@Evan[b] -- I think I agree with you for the most part, and the framework I'm using seems to be handling that situation quite well. (I must admit, I didn't even give a thought to this at all, but thank God someone did.) Either way, your last statement is dead on with my thinking. My gripe is really "requiring" that slash to be there for an end user. As long as your application/server setup is handling it and doing the right thing, why "require" it?
~
:wq!