GaffneyWare

Thoughts on Software Development from Michael Gaffney

URL Scheme Design

Published: 3:11 PM GMT-05, Monday, 14 November 2005

I was recently working on the URL scheme for a new web app. In the past, I didn't give this step much thought, but this time I wanted to make the URLs more in line with a REST style interface. There is plenty of information on the web about URLs but I couldn't find anything that really addressed the dynamic nature of a web application with respect to URLs. I was looking for a good design pattern but I didn't come across any. Lacking a good design pattern, I analyzed some web sites to see who had a good URL scheme. In my opinion, one of the better URL schemes is Flickr's. After analyzing the Flickr URL scheme, I came up with these notes.

Create views of your data -- The first level of the URL path should partition your data along it's major axes. For example, http://flickr.com/photos and http://flickr.com/groups.

Allow users to create 'friendly' URL names -- After you signup, Flickr allows you to create a user-friendly alias for your account which is used to construct URLs to your data. For example, if I select 'foobarman' as my alias, I get the following hierarchy of URLs pointing to my data:

  • http://flickr.com/photos/foobarman
  • http://flickr.com/photos/foobarman/tags
  • http://flickr.com/photos/foobarman/sets
  • http://flickr.com/photos/foobarman/favorites

 

Create a global hierarchy that mirrors the user hierarchy -- Flickr does this in some cases but not in others. For example, http://flickr.com/photos/tags shows a global tag cloud but http://flickr.com/photos/favorites does not show a global favorites.

As a side note: http://flickr.com/photos/favorites does two bad things. First it doesn't show a global favorites page instead it shows a Flickr 'Page Not Found' error page. Second, it returns an HTTP status code of 200 instead of the more appropriate 404 status code.

Every level of a URLs path should return an appropriate representation -- For example each of these URLs would return an appropriate representation of the data for that level:

  • http://flickr.com/photos/foobarman/archives/date-posted/2005/11/14/
  • http://flickr.com/photos/foobarman/archives/date-posted/2005/11/
  • http://flickr.com/photos/foobarman/archives/date-posted/2005
  • http://flickr.com/photos/foobarman/archives/date-posted
  • http://flickr.com/photos/foobarman/archives

 

This list is not complete but I think it's a good start. Please let me know of any other good design points so I can add them to the list.

Technorati:

– Category: web2

5 Comments · Add a comment

Steve M. · Tuesday, 18 September 2007 1:09 AM

I also want to know dynamic nature of web application(URLS).Any help would be appreciated .By the way great post.

Mike Schinkel · Thursday, 5 October 2006 9:29 PM

Hi. You might be interested to know about a new website/wiki I have created entitled WellDesignedUrls.org with the following mission:

"Providing best practices for URL design, and to raise awareness of the importance of URL design especially among providers of server software and web application development tools."

It's wonderful that people are finally starting to pay attention to URL design after so many years! I hope you'll consider contributing to the wiki and helping to generate a resource for best practices on good URL design.

neon · Saturday, 29 July 2006 5:10 AM

A lot of information is available on it by searching for "search engine friendly URLs". mod_rewrite is a common way to implement this type of scheme.

http://www.evision.com.pk/web-design.html

Mario Rizzuti · Thursday, 5 January 2006 7:12 AM

I was thinking about these very same ideas today for a project I am working on.

Maybe the lenght and simplicity of the urls have some importance.

You may type the complete url in the browser without going to the home page or using the site's input box (but the scheme has to be kept really short, intuitive and simple).

Probably, the url scheme for web applications could be used as an optional, rudimentary command-line if the designer anticipated that use.

groogs · Monday, 14 November 2005 4:31 PM

This post raises an issue that a lot of web developers don't think about.

There are many sites that use the tired old "?action=edit§ion=users&id=2345" type scheme, which is just difficult to read. There are a lot of benefits to having a url like "/users/edit/2345" or even "/users/edit?id=2345" instead, for both users and developers.

For developers, one benefit is that relative links become simple. For example, if you're on "/users" (which would be, for example, a users list), you can make links like href="edit/2345" which will link to the proper page (really, it's a better pratice to use absolute URLs, but that even becomes easy because you can usually get the url PATH very easily).

Another huge benefit is that forms can be posted to the current location, and you don't have to pass around a bunch of hidden fields -- your form just has to hold the variables that are relevant to that form.

For users, it becomes easier to navigate your site. For example, if they're at "/users/edit/2345", it's pretty common sense that you'd just delete the "edit/2345" part to get back to "/users". (Granted, only the more advanced users will do this, but as a developer, you're probably one of these types of users..). As pointed out in the original article, it makes nicer bookmarks or links to give to other users, ie, "flickr.com/photos/foobarman".

It could also be argued that it tends to lead to stronger security, it forces you to think about combinations of parameters, making it harder for a vulnerability to exist from passing an unexpected combination of variables. This is a pretty weak argument though.

For developers new to this concept, it's not overly difficult to implement. A lot of information is available on it by searching for "search engine friendly URLs". mod_rewrite is a common way to implement this type of scheme. Personally, I'm a PHP developer, and the way I usually implement this is using two methods:

My links are actually domain.com/index.php/users/edit/2345. In index.php, I can get the rest of the url by looking at $_SERVER. I then setup mod_rewrite with:

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*) index.php

This redirects any URLs that aren't to existing real files or directories to load index.php/url, for example "domain.com/users/edit/1234" gets rewritten to "domain.com/index.php/users/edit/1234". Basically, the user sees the first url, the server sees the second rewritten url.

(found via digg)