Nested URLs without nested serialization

1,114 views
Skip to first unread message

Gregory Taylor

unread,
Dec 13, 2012, 5:24:59 PM12/13/12
to django-res...@googlegroups.com
Greetings,

We're trying to nest an object as far as URL scheme, without doing a nested resource (as far as serialization is concerned). For example, we've got CRUD and List views like this:

GET /api/quiz/ (list)
GET /api/quiz/<id>/ (CRUD)

We want to be able to get a list of questions under a quiz:

GET /api/quiz/question/ (list)

Or a specific question under a quiz:

GET /api/quiz/question/<id>/

We want to avoid this, which would be the current workaround:

GET /api/quiz-question/<id>/?quiz_id=<id>

We're trying to do this now, but are having to do what feels like a nasty workaround:

    # We don't technically want this view, but it shuts reverse() up.
    url(r'^quiz-question/$', QuizQuestionList.as_view(), name='quiz-question-list'),
    # Lists all questions beneath a quiz. I think we'd use http://django-rest-framework.org/api-guide/filtering.html#filtering-against-the-url
    url(r'^quiz/(?P<quiz_pk>\d+)/question/$', QuestionsForQuizList.as_view(), name='questionsforquiz-list'),
    # Get a specific questions within a quiz, but 404 if the question isn't FK'd to the quiz in the URL
    url(r'^quiz/(?P<quiz_pk>\d+)/question/(?P<pk>\d+)/$', QuizQuestionDetail.as_view(), name='quiz-question-detail'),

This seems messy, given that we only really want the latter two URLs. Calling the first one would result in an absolutely massive queryset, and it's just not something we want. We could make it to where nobody has authorization to use it, but I'd rather just do away with it entirely.

Second question is how to associate certain regex groups (kwargs as far as Django is concerned) with different things. Since in our last URL entry, we've got `quiz_pk` and `pk`.

Any ideas would be appreciated,

Greg

Alan Justino (alanjds)

unread,
Aug 21, 2013, 10:50:21 AM8/21/13
to django-res...@googlegroups.com
Hi.

Aside from "how", as this http://django-rest-framework.org/api-guide/filtering.html#filtering-against-the-url fits nicely (thanks for the tip), this week I coded a NestedSimpleRouter that automates the creation of routes for this case.

router = routers.SimpleRouter()
router.register(r'quiz', QuizViewSet)

quiz_router = routers.NestedSimpleRouter(router, r'quiz')
quiz_router.register(r'questions', QuestionViewSet)

url_patterns = patterns('',
url(r'^', include(router.urls))
url(r'^', include(quiz_router.urls)), )

This creates the following URLs:

^quiz/$ [name='quiz-list']
^quiz/(?P<pk>[^/]+)/$ [name='quiz-detail']
^quiz/(?P<nested_1_pk>[^/]+)/questions/$ [name='question-list']
^quiz/(?P<nested_1_pk>[^/]+)/questions/(?P<pk>[^/]+)/$ [name='question-detail']
And, if you want not 'quiz-detail' to be available, just comment the line: url(r'^', include(router.urls))

Now my questions:
1) Does it makes sense for you?
2) Is this somewhat useful, or I should stop spending time coding such feature?
3) Is the usage "ok" or needs some drastic change?

I am thinking that automaticaly converting <nested_1_pk> to a Quiz object would be an overkill, so I am asking before start coding more.

I appreciate if any feedback,
Alan.

Gregory Taylor

unread,
Aug 21, 2013, 10:58:57 AM8/21/13
to django-res...@googlegroups.com
This was almost 9 months ago, so I've largely forgotten what the state of DRF was at that point in time. I think the hangup we were running into was with the auto doc site freaking out. The simple fix was to just not use the doc generator and design the URLs exactly how I wanted (we don't tend to use routers).

Not sure if that's helpful for you.


--
You received this message because you are subscribed to a topic in the Google Groups "Django REST framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-rest-framework/Sv03dCVNn-U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-rest-fram...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
Reply all
Reply to author
Forward
0 new messages