using file based URIs or not

Question

Of course, the traditional method is to let the filesystem and your webserver work out the urls. E.G., www.example.com/index.html -> /var/www/public_html/index.html

But I've noticed a trend in which, as opposed to letting the webserver do the mapping for you, you do it yourself (e.g., Rails and its routes config file, so /index is mapped to app/controllers/index.rb or w/e you set it up to be).

Now I realize that one of the advantages of the latter approach is that nobody can view your source code if the server starts failing to execute stuff or w/e; but for compiled CGIs, this obviously isn't a problem.

Is there any real reason (REST-related ideas aside) to parse the URLs yourself? (I have a feeling that it's slower than letting Apache do it.)

Answer 1

The thing about defining routes yourself (as the ruby example you gave) is that the URIs don't have to point to actual files. In case of MVC frameworks they simply point to actions. You could have several actions be handled by the same controller, which is in the same class and in the same file. Here's a nice (ASP.NET MVC) example of what routing gives you (in particular take a look at the section on search).

The extension of that is that URIs don't point to files, they point to resources. Such resources could be backed by files, or database tables, or some poor guy who writes out html for every request by hand and taps the 0's and 1's using Morse code.

Answer 2

The biggest reason to have code behind a URL is that it allows URLs that aren't backed by a file to respond to queries. You may want to have a CGI on disk for every URL that you could possibly want to serve up, but you probably don't. You could do /products.cgi?productid=12, but a prettier URL for humans to use is /products/12.