Real-world examples of practical examples of Django URL routing

Examples of practical examples of Django URL routing in a typical app

Let’s start with a realistic urls.py for a mid-sized project. This isn’t a toy “polls” app; think SaaS dashboard with users, billing, and a public marketing site.

## config/urls.py
from django.contrib import admin
from django.urls import path, include
from django.views.generic import TemplateView

urlpatterns = [
    path("admin/", admin.site.urls),

#    # Public marketing pages
    path("", TemplateView.as_view(template_name="pages/home.html"), name="home"),
    path("pricing/", TemplateView.as_view(template_name="pages/pricing.html"), name="pricing"),

#    # Auth and user management
    path("accounts/", include("accounts.urls")),

#    # App domains
    path("projects/", include("projects.urls")),
    path("billing/", include("billing.urls")),

#    # API (versioned)
    path("api/v1/", include("api.v1.urls")),
]

This is a simple but powerful example of how Django URL routing scales: the project-level file stays thin, and each app owns its own URL configuration. Many of the best examples you’ll see in open-source Django projects follow this pattern because it keeps config/urls.py readable even when the product grows.

Example of user account URLs with named routes and slugs

User-facing URLs are where you feel routing decisions the most. Here’s an accounts/urls.py that shows examples of practical examples of Django URL routing focused on clarity and SEO-friendly paths.

## accounts/urls.py
from django.urls import path
from . import views

app_name = "accounts"

urlpatterns = [
    path("login/", views.LoginView.as_view(), name="login"),
    path("logout/", views.LogoutView.as_view(), name="logout"),
    path("signup/", views.SignupView.as_view(), name="signup"),

#    # Profile by username slug
    path("@<slug:username>/", views.ProfileDetailView.as_view(), name="profile"),

#    # Settings
    path("settings/", views.SettingsView.as_view(), name="settings"),
]

A few real examples worth stealing:

• Prefixing all account-related paths with accounts/ at the project level, then keeping them clean inside the app.
• Using @<slug:username>/ is a nice, social-style pattern that users instantly recognize.
• Naming routes (name="login", etc.) lets you reverse URLs in templates and views without hardcoding strings.

In production, this style gives you readable URLs like /accounts/@jamie/ and /accounts/settings/, which are easy to remember and to link to from emails or external docs.

Best examples of nested resource routing for projects and tasks

Nested resources are where people often get tangled. Here’s a set of real examples for a project management app with projects and tasks.

## projects/urls.py
from django.urls import path
from . import views

app_name = "projects"

urlpatterns = [
#    # Project list and creation
    path("", views.ProjectListView.as_view(), name="list"),
    path("new/", views.ProjectCreateView.as_view(), name="create"),

#    # Project detail, update, delete
    path("<uuid:pk>/", views.ProjectDetailView.as_view(), name="detail"),
    path("<uuid:pk>/edit/", views.ProjectUpdateView.as_view(), name="update"),
    path("<uuid:pk>/delete/", views.ProjectDeleteView.as_view(), name="delete"),

#    # Nested tasks under a project
    path("<uuid:project_id>/tasks/", views.TaskListView.as_view(), name="task_list"),
    path("<uuid:project_id>/tasks/new/", views.TaskCreateView.as_view(), name="task_create"),
    path("<uuid:project_id>/tasks/<int:task_id>/", views.TaskDetailView.as_view(), name="task_detail"),
]

These examples of practical examples of Django URL routing highlight a few current best practices:

• Use uuid for primary keys when you don’t want guessable IDs.
• Keep nested resources readable: projects/<uuid>/tasks/<int>/ is easy to understand for both humans and API clients.
• Maintain consistent endings: new/, edit/, delete/ so routes are predictable across the app.

This pattern works nicely with modern front ends and is easy to document in API reference pages, which matters if you’re publishing public APIs.

Examples include API-style Django URL routing (with versioning)

If you’re building APIs, you probably care about versioning and clean, predictable patterns. Here’s an example of api/v1/urls.py that shows how many teams structure their routes in 2024.

## api/v1/urls.py
from django.urls import path, include
from . import views

app_name = "api_v1"

urlpatterns = [
#    # Health check endpoint for uptime monitors
    path("health/", views.health_check, name="health"),

#    # Auth endpoints
    path("auth/login/", views.api_login, name="login"),
    path("auth/logout/", views.api_logout, name="logout"),

#    # User endpoints
    path("users/", views.UserListCreateView.as_view(), name="user_list_create"),
    path("users/<int:pk>/", views.UserRetrieveUpdateView.as_view(), name="user_detail"),

#    # Projects endpoints (mirroring the web app structure)
    path("projects/", views.ProjectListCreateView.as_view(), name="project_list_create"),
    path("projects/<uuid:pk>/", views.ProjectRetrieveUpdateView.as_view(), name="project_detail"),
]

In many open-source and corporate codebases, examples of practical examples of Django URL routing for APIs follow this pattern:

• Prefix all API routes with api/ and a version like v1/.
• Use nouns (users/, projects/) rather than verbs in the path.
• Keep HTTP verbs (GET, POST, PATCH, DELETE) in the methods, not the URL.

If you’re mixing Django with Django REST Framework, you’ll see router-based examples as well, but even then, versioned prefixes and noun-based paths are still the norm.

For guidance on API design patterns in general (even though it’s not Django-specific), the US Digital Service has API guidance at https://api.data.gov that aligns well with this style.

SEO-focused examples of practical examples of Django URL routing with slugs

If your app has content that should rank in search engines—articles, products, documentation—slugs are your friend. Here’s a content app that shows how to design URLs that search engines and humans both like.

## blog/urls.py
from django.urls import path
from . import views

app_name = "blog"

urlpatterns = [
    path("", views.PostListView.as_view(), name="list"),

#    # Category listing
    path("category/<slug:category_slug>/", views.CategoryDetailView.as_view(), name="category"),

#    # Post detail with date and slug
    path(
        "<int:year>/<int:month>/<int:day>/<slug:slug>/",
        views.PostDetailView.as_view(),
        name="detail",
    ),
]

These real examples show how Django URL routing can support content-heavy sites:

• Year/month/day in the URL helps avoid slug collisions and gives readers context.
• Slugs (<slug:slug>) keep titles readable: /2025/07/04/best-django-routing-patterns/.
• Category slugs provide topical organization: /blog/category/django-routing/.

If you care about search performance and crawlability, this style mirrors what you’ll see on high-traffic content sites and in recommendations from large institutions. For general guidance on web content structure, Harvard’s digital accessibility and content standards at https://accessibility.huit.harvard.edu are worth a look, even though they’re not Django-specific.

Role-based access and admin-style examples of Django routing

Another practical example of Django URL routing comes up when you need separate dashboards for different roles, such as admins, staff, and regular users.

## dashboard/urls.py
from django.urls import path
from . import views

app_name = "dashboard"

urlpatterns = [
#    # Default user dashboard
    path("", views.UserDashboardView.as_view(), name="user_home"),

#    # Staff-only dashboard
    path("staff/", views.StaffDashboardView.as_view(), name="staff_home"),

#    # Admin-only dashboard
    path("admin/", views.AdminDashboardView.as_view(), name="admin_home"),
]

The routing itself doesn’t enforce permissions—that’s the job of decorators or class-based view mixins—but this pattern keeps URLs clear:

• /dashboard/ for regular users
• /dashboard/staff/ for staff
• /dashboard/admin/ for higher-level admin tools

In a security review, auditors can easily see which views to check for permission handling based on this structure. That’s a small but real advantage of clean URL routing.

If you’re building health or medical dashboards that handle sensitive data, it’s worth pairing good routing structure with privacy and security best practices recommended by organizations like the National Institutes of Health and CDC, even if your app is not directly tied to clinical care.

Examples include internationalization and localized URL routing

Modern apps often need to support multiple languages. Django gives you tools to localize URLs using i18n_patterns. Here’s a practical example of Django URL routing with language prefixes.

## config/urls.py
from django.conf import settings
from django.conf.urls.i18n import i18n_patterns
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path("admin/", admin.site.urls),
]

urlpatterns += i18n_patterns(
    path("", include("pages.urls")),
    path("accounts/", include("accounts.urls")),
)

This gives you URLs like /en/accounts/login/ and /es/accounts/login/. Real examples in international products often combine this with translation of the page content, not the URL segments themselves, to keep paths stable while still signaling language.

If you’re shipping to multiple regions, this is one of the best examples of how Django URL routing can support internationalization without turning your urls.py into a mess.

Front-end SPA integration: hybrid Django + React/Vue examples

A lot of teams in 2024–2025 are running Django on the back end with a JavaScript SPA on the front. You still need Django URL routing to serve the SPA shell and to expose APIs.

Here’s a typical pattern:

## config/urls.py
from django.contrib import admin
from django.urls import path, include, re_path
from django.views.generic import TemplateView

urlpatterns = [
    path("admin/", admin.site.urls),

#    # API endpoints
    path("api/v1/", include("api.v1.urls")),

#    # Catch-all for SPA routes
    re_path(r"^(?!api/).*$", TemplateView.as_view(template_name="spa/index.html"), name="spa"),
]

This example of Django URL routing does a few important things:

• All API traffic lives under /api/v1/.
• Everything else (except /admin/) falls back to the SPA index, which then lets the front-end router handle the rest.

You’ll see real examples like this in many SaaS products that migrated from server-rendered Django templates to React or Vue while keeping Django as the API and auth layer.

Putting it together: patterns you can actually copy

To recap, the examples of practical examples of Django URL routing above show patterns that hold up in production, not just in tutorials:

• Thin project-level urls.py, with each app owning its own routing.
• Clean, named routes for accounts and profiles (/accounts/login/, /accounts/@username/).
• Nested resources with predictable suffixes (new/, edit/, delete/).
• API-style routing with versioning and noun-based paths.
• SEO-friendly slugs and date-based paths for content.
• Role-based dashboards that map cleanly to permission layers.
• Language-aware URLs using i18n_patterns.
• SPA-friendly catch-all routes that coexist with APIs.

When you look at the best examples in mature Django codebases on GitHub, you’ll see variations on these same ideas. The syntax changes a bit over Django versions, but the principles stay boring and reliable—which is exactly what you want from your routing layer.

If you want to go deeper into Django’s official guidance, the URL dispatcher section of the Django docs at https://docs.djangoproject.com remains the authoritative reference and pairs nicely with the real examples shown here.

FAQ: examples of common Django URL routing questions

Q: Can you give an example of namespaced URLs and why they matter?
Yes. Namespacing avoids collisions between apps that might both define a detail or list route.

## config/urls.py
from django.urls import path, include

urlpatterns = [
    path("blog/", include("blog.urls", namespace="blog")),
    path("shop/", include("shop.urls", namespace="shop")),
]

In templates, you then use {% url 'blog:detail' slug=post.slug %} versus {% url 'shop:detail' pk=product.pk %}. This is one of the best examples of how Django URL routing prevents subtle bugs in larger projects.

Q: How do I handle trailing slashes in Django routes?
By default, Django’s APPEND_SLASH setting redirects /login to /login/. Most real examples stick with the default, using trailing slashes everywhere. If you turn it off, be consistent and test thoroughly, especially for API clients.

Q: Are there examples of mixing path and re_path in the same project?
Yes. Use path for most routes and re_path only when you genuinely need regex flexibility, such as a SPA catch-all route or legacy URL support. The SPA integration example above is a classic case.

Q: What’s a practical example of URL reversing in views?
Instead of hardcoding /accounts/login/, you use Django’s reverse function:

from django.shortcuts import redirect
from django.urls import reverse

def logout_then_login(request):
#    # ... perform logout logic ...
    return redirect(reverse("accounts:login"))

This pattern shows up in many examples of practical examples of Django URL routing because it keeps routes maintainable when paths change.

Q: Where can I find more real examples of Django URL routing in the wild?
Look at large open-source Django projects on GitHub, such as the Django project itself or popular third-party apps. Combine that with the official docs and patterns from serious organizations, and you’ll have more than enough real examples to guide your own routing decisions.