Is it better to handle friendly/clean/pretty URLs with mod_rewrite or a language like PHP?

I'm developing my first decent-sized PHP site, and I'm a bit confused about what the "right way" (assuming there ever is such a thing) to handle clean/friendly/pretty URLs in the application.

The way I see it, there are two main options (I'll use a simplified social news site as an example):

1. Use mod_rewrite to handle all potential URLs. This would look similar, but not identical, to the follow开发者_开发技巧ing:

RewriteRule ^article/?([^/]*)/?([^/]*)/?([^/]*) /content/articles.php?articleid=$1&slug=$2
RewriteRule ^users/?([^/]*)/?([^/]*) /content/users.php?userid=$1&username=$2
RewriteRule ^search/?([^/]*)/? /content/search.php?query=$1

2. Pass everything to some handler script and let it worry about the details:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) handler.php?content=$1

Clearly this is all untested "air code," but you get the point.

• Is one of these two ways going to be seriously slower than the other? Presumably the mod_rewrite is slower, since I'll be forced to use .htaccess files for this.
• Are there serious disadvantages to either of these approaches?
• Is there a "best practice" for this sort of thing, or is it something that each developer tends to decide for themselves? I know WordPress uses option two (though it was more trouble than it was worth when I investigated exactly how they did it).

Option 1 (.htaccess and several .php files) was often used "in the past" ; now, I see option 2 (every request going through one .php file) used a lot more.

The main advantages I see with option 2 are :

• you can add / modify any kind of URL without having to change any physical file like .htaccess
  • which means the format of the URLs can be configured in the admin section of your application, for example
• you only have one entry point to your PHP code.
  • which means everything goes though index.php : if you need some code executed for all requests, put it there, and you're sure it'll always be executed.
  • That's used a lot with MVC frameworks, for instance.

A couple of years ago, I would have gone with option 1 ; now that I use MVC and Frameworks, I always go with option 2.

Really this is the "are frameworks worth using?" question in disguise.

Using mod_rewrite to define your URL routes is quick and easy (if you understand regular expressions...) but your application code is oblivious to the URLs unless you duplicate the information somewhere.

Usually, people duplicate this information many times without thinking about it, by hard-coding URLs in the links in their views, or in redirects. This is really messy, and will one day cause pain when you decide to change the URL structure of your site halfway through development. You're bound to miss one and end up with a 404 somewhere.

Using a routing component in your application (such as the one in Symfony) means you can attach names to your routes, allowing you to define your URLs once and re-use them many times:

# apps/frontend/config/routing.yml
homepage:
  url:   /
  param: { module: default, action: index }

This makes it really easy to link to pages of your site without repeating yourself:

<?php echo url_for('@homepage') ?>

Use option #2 - why? RewriteRules in .htaccess are powerful tool, but they're some kind of static. I mean you cannot easily manage then using PHP (or whatever you're going to use). Also .htaccess doesn't provide so much flexibility, but has some advantages (for example: it's a bit faster).

Option #2 also need .htaccess as you noticed, but in most cases RewriteRule takes the following form:

RewriteRule (.\*) index.php

Where index.php is your front controller.

The biggest advantage (IMO) of this soultion is that each route is described in PHP (or whatever you use) so accessing these routes, modifying them is much easier. Furthermore these routes can be used then not only for changing URL into set of variables, but also in opposite way - to create URL from set of variables.

I think the following example (from Symfony framework) will explain what I am talking about:

// apps/.../config/routing.yml - Describes routing rules
post:
   url:          /read/:id/:slug
   params:       { module: blog, action: index }
   requirements: { id: \d+, slug: \w+ }

// apps/.../modules/blog/templates/indexSuccess.php - template for index action
<?php echo link_to($post['title'], '@post?id=' . $post['id'] . '&slug=' . $post['slug']); ?>
//creates: <a href="/read/123/my-first-blog-post.html">My first blog post</a>

Now whenever you change your rounting.yml file and change /read/:id/:slug into /:slug_:id all your links in application will turn into /my-first-blog-post_123.html.

Doing such and others things when you use option #2 is much easier.

As far as I can see, any possible performance differences between those methods are really minuscule and relevant only for really, really high-traffic sites.

I think there is no "best practice" as such, both methods are equally often used. If your project structure allows it, and you're more at home with parsing the URL in PHP (where the rest of your project is), put everything through one controller file, and let your application handle the rest.

If performance is really of the essence, I suspect that having Apache handle the addresses is faster, because there is no interpreted language in between. (I have no hard data for this, though). But as I said, you're probably best of choosing whichever is going to be most maintainable for you in the long term.

Clean pretty URLs appear to be provided by PHP-script-based popular content management system Drupal using a combination of modrewrite rules in .htaccess and plug-in PHP Drupal modules such as path and pathauto.

Given the success and popularity of this tool - and its ability to run on the most modest of shared hosting, I think this would be your answer.