Django URL Design

Question

I often find myself falling into a world in which I am not so sure about the URLs that I came up with. I think that's mainly because I have a few questions regarding URL design in django that remain unanswered.

Say, I have built a public profile page for my site users. It can be accessed by providing an user id. Should the user id be part of the URL (ie. /profile/<userid>/) or should it be provided in the querystring (/profile?userid=<userid>)? And why?

I use AJAX extensively in my project. Should the AJAX URLs be designed differently from their counterparts? Is there a design pattern for this purpose?

Answer 1

There isn't any hard-and-fast rule here. I'd say that anything which is reasonably static should use the /profile/<userid>/ format. GET parameters - ?userid=<userid> - should be reserved for things that are more dynamic, are just difficult to encode as part of the URL (such as a set of search terms), or when you need several parameters at once and can't count on the order.

Answer 2

Django discourages the use of query strings and encourages the use of pretty URLs. You just have to set them up properly in your URLconf. If you haven't read the Django Book (available freely online), you should. It talks about this in chapter 3:

A Word About Pretty URLs

If you’re experienced in another Web development platform, such as PHP or Java, you may be thinking, “Hey, let’s use a query string parameter!” — something like /time/plus?hours=3, in which the hours would be designated by the hours parameter in the URL’s query string (the part after the ?).

You can do that with Django (and we’ll tell you how in Chapter 7), but one of Django’s core philosophies is that URLs should be beautiful. The URL /time/plus/3/ is far cleaner, simpler, more readable, easier to recite to somebody aloud and … just plain prettier than its query string counterpart. Pretty URLs are a characteristic of a quality Web application.

Django’s URLconf system encourages pretty URLs by making it easier to use pretty URLs than not to.

This chapter details how and why to do this!