To clarify camflan's explanation, let's suppose you have
- the rule
url(regex=r'^user/(?P<username>\w{1,50})/$', view='views.profile_page')
- a in incoming request for
http://domain/user/thaiyoshi/?message=Hi
The URL dispatcher rule will catch parts of the URL path (here "user/thaiyoshi/") and pass them to the view function along with the request object.
The query string (here message=Hi) is parsed and parameters are stored as a QueryDict in request.GET. No further matching or processing for HTTP GET parameters is done.
This view function would use both parts extracted from the URL path and a query parameter:
def profile_page(request, username=None):
user = User.objects.get(username=username)
message = request.GET.get('message')
As a side note, you'll find the request method (in this case "GET", and for submitted forms usually "POST") in request.method. In some cases it's useful to check that it matches what you're expecting.
Update: When deciding whether to use the URL path or the query parameters for passing information, the following may help:
- use the URL path for uniquely identifying resources, e.g.
/blog/post/15/ (not /blog/posts/?id=15)
- use query parameters for changing the way the resource is displayed, e.g.
/blog/post/15/?show_comments=1 or /blog/posts/2008/?sort_by=date&direction=desc
- to make human friendly URLs, avoid using ID numbers and use e.g. dates, categories and/or slugs:
/blog/post/2008/09/30/django-urls/