Django-rest-framework: Document how to register function based API views in url route in the API docs

[auvipy]

currently I found no reference for this looking at views and routes documentation.

[xordoquy]

Routers work with ViewSet while function based view only inherit from APIView.
This isn't a documentation issue.

[auvipy]

then how should I map that on router? register the function based view in router instead of viewset?

[xordoquy]

I can't think of a simpler way then to write your own router for that.

[auvipy]

then DRF should have built in solutions/guides for that :)

[auvipy]

@tomchristie what do you think?

[xordoquy]

Thoughts about that:

1. It's simple enough to write a ViewSet
2. It's fairly complex to figure that a single function can handle the 5 actions a ViewSet can do: list / create / show / update / delete.

Maybe create a 3rd party could solve this issue, I saw a similar question on SO this week.

[auvipy]

without binding in router, how should I handle function based API view in? how can I expose them in url?

[tomchristie]

We don't support function based views with routers, and I wouldn't want us to either.

If the custom @detail_route/@list_route decorators don't fit what you need then I'd suggest configuring the view in the URL conf explicitly.

[auvipy]

like normal django views right?

On Mon, Nov 16, 2015 at 7:57 PM, Tom Christie [email protected]
wrote:

We don't support function based views with routers, and I wouldn't want us
to either.

If the custom @detail_route/@list_route decorators don't fit what you
need then I'd suggest configuring the view in the URL conf explicitly.

—
Reply to this email directly or view it on GitHub
https://github.com/tomchristie/django-rest-framework/issues/3633#issuecomment-157034845
.

[tomchristie]

Yup

[auvipy]

thanks for clarification. A little indicator to this in the doc will really save both my and your precious time i guess :)

[AlJohri]

Gotta agree with this one. Had no idea how to register the function based views in urls.py.

[rizplate]

I agree with original OP, i know its recommended to write model and model serializer and viewset etc, however many cases do not fall neatly in these categories.

I had to really dive into all the code for understanding all the mixin and other things to get a very simple thing work.

sometime people just want to write a handler to parse posted json, and all the urls patterns do not fall neatly into imaginary, best-practices patterns made up by someone's opinion.

many of the functions or internal interactions of mixing, view sets , get_object etc are not obvious to someone from outside.

I know you all developers working on it know a lot, but community is sponsoring this project so if you have knowledge put it in documentation, otherwise someone else will fix those issues and create a better project .

a previous comment on this thread has very strong opinions about what is correct way and what is not? who is in charge of this project, can we change the documentation or create a fork to change the way simple things are handled.

[auvipy]

@rizplate pr with suggested changes are wellcome

[rpkilby]

Gotta agree with this one. Had no idea how to register the function based views in urls.py.

Hi @AlJohri, API views are an extension of standard Django views. As far as I understand it, there isn't anything special required to add them to your app's url_patterns.

---

I agree with original OP, i know its recommended to write model and model serializer and viewset etc, however many cases do not fall neatly in these categories.

Hi @rizplate, these classes are recommended in so far as they reduce the amount of boilerplate necessary to create fully functional sets of views that map to your database models. Beyond that, there is no recommendation on the correct way of using the framework.
That said, certain classes provide certain functionality, and they integrate accordingly. For example, the ViewSet is designed to be registered with a Router, and a Router outputs a set of url patterns that are suitable for Django's URL config. APIView/@api_view are simple extensions of existing Django view classes/functions and don't need or have the ability to be registered with a Router.

who is in charge of this project, can we change the documentation or create a fork to change the way simple things are handled.

There is a team of ~5 maintainers, including the original project creator. Documentation PRs are always welcome. If you'd like to see changes made to this project, there is an established process for contributing. Keep in mind that a lot of changes aren't accepted into the core framework, as they're better suited as a third party package.

[wdifruscio]

Bump :)

[xordoquy]

I'm locking this thread as it serves no purpose to just bump this issue.
If anyone wants a documentation improvement we'll consider PR about it based on their own merit.
I'm not really inclined to see DRF documentation duplicate content from Django's documentation such as how to configure urls but I'm fine to improve the documentation if that part isn't clear enough.