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/