7 ms·

Django REST framework 2.3 released: ViewSets and Routers

103 points by tomchristie 13y ago

madeofpalk 13y ago
What's with the nav box completely blocking the document? http://cl.ly/OnPN http://cl.ly/OnPN Running Chrome 28.0.1496.0 dev
- tomchristie 13y ago
  Note sure. I seem to be able to replicate that if the browser window is exactly 727 pixels wide, but otherwise everything displays just fine for me on Chrome 26.0.1410.65. Will look into it later. Edit: Are you seeing this for all browser widths, or just specific ranges?
  - davis_m 13y ago
    I took a quick video of it on my machine: OSX 10.8.3, Chrome Canary Version 28.0.1499.0 canary. It doesn't happen on any other browser on my machine (Vanilla Chrome, Firefox, FirefoxNightly) http://screencast.com/t/2DOssUNcJrGt http://screencast.com/t/2DOssUNcJrGt
    - tomchristie 13y ago
      Thanks, appreciated.
      - raimondious 13y ago
        While you're in there, there's a conflict in the content of the tutorial, at the end of the URLs section: http://django-rest-framework.org/tutorial/quickstart.html http://django-rest-framework.org/tutorial/quickstart.html
        tomchristie 13y ago
        Ooops. Fixed now - thank you!
woakas 13y ago
awesome thanks :)
ditados 13y ago
Anyone care to weigh in about using this vs., say, TastyPie?
- OMBUG 13y ago
  Last I tried this (2.1?) it took a hell of a lot more boilerplate than TastyPie, and I had a few problems that necessitated changing the source a bit. But maybe I was using it wrong (didn't spend a huge amount of time with it). The auto generated web interface is nice though.
  - antihero 13y ago
    Personally I find it much more powerful and organised than TastyPie, and you can use it for much more basic stuff. You don't actually have to do REST at all. Regarding the boilerplate - IIRC the tutorial starts you off with lots of boilerplate then shows you how to refactor it so it is not needed.
  - tomchristie 13y ago
    Author here... The boilerplate comment is definitely valid, and is pretty much what this release was intended to address. We've now introduced ViewSets (an extension of class based views that is similar to Rail's controllers) and Routers, which make it super quick and easy to get your API up and running. The updated README should give you a good idea how simple the APIs can be now: https://github.com/tomchristie/django-rest-framework https://github.com/tomchristie/django-rest-framework I get the impression that what TastyPie does really well is convention-over-configuration - making a bunch of really sensible design decisions on your behalf. What (I hope) REST framework does really well is staying close to Django's conventions, and being easy to customize all the way through, plus of course the browseable API. Either way, there's certainly plenty of folks happy with both frameworks.
    - gtaylor 13y ago
      I'll take boilerplate over magic any day. The thing that irked me the most about TastyPie was the magic and lack of obvious understanding of what was happening under the hood (without source diving). The Zen of Python has something to say about this.
lefrancaiz 13y ago
This is great stuff. The viewsets are about to save me lots of repeated code!
AUmrysh 13y ago
Using 2.1 of this framework and an HBase database, we've been able to reduce load times for data in one of our applications from about 30 seconds down to less than 1. Arguably, this had a lot to do with HBase, but rest-framework is actually really nice and seems to work well in regards to performance.
jeffheard 13y ago
Can anyone comment on DRF's relationship to GeoDjango and whether it's pretty seamless to work with GeoJSON vs. WKT?
- tomchristie 13y ago
  You might want to take a look at this: https://github.com/mjumbewu/django-rest-framework-gis https://github.com/mjumbewu/django-rest-framework-gis
csmatt 13y ago
When I found this for http://www.socialocale.com http://www.socialocale.com it was a godsend! It made the weird database operations a breeze when working with third-party libs like Userena. It also gave me a concise, modular way to get/put information. If your project is complex, I feel like the Django Rest Framework will be by your side the whole way. It's very well thought out and nicely documented.
mattdeboard 13y ago
I feel very comfortable with Tastypie, and have pretty well internalized its API. I've got most custom code down to muscle memory. Because of this I don't feel constrained by Tastypie at all. That said it is very "Django"-y, meaning it's got a high level of abstraction, very opinionated but provides hooks for everything. It's also pays a huge amount of attention to testing. All that aside I did evaluate DRF for my last project. Tastypie's Django 1.5 support didn't exist, it had some weird interaction issues with our database setup, and it has a huge amount of outstanding issues & pull requests. I spent like 2 days working with DRF and it felt clumsy for me (read: not objectively clumsy, I was just used to thinking about exposing data to a hypermedia API in a particular way). Honestly I just got annoyed by the CBV part. I know some people love them and I'm sure they're great and all, just wasn't for me. edit: frankly they're doing the same thing, they're both well-written and -maintained. It's just about which API you prefer to work with.
- tomchristie 13y ago
  > Honestly I just got annoyed by the CBV part. There's a bunch of things in 2.3 that should make working with the CBVs a much more pleasant experience. * There's no longer any inheritance from Django's GCBV machinery, specifically SingleObjectMixin, and MultipleObjectMixin. The base class was simple enough that it wasn't really necessary. That means no more browsing across multiple codebases, and less class hierarchy to think about. * Previously there were three base classes, now there's just a single simplified GenericAPIView. * Several attributes and methods have been moved to pending deprecation or refactored and simplified. * Using ViewSets means less verbose, repeated view code and easier URL configuration. Additionally, all the changes are covered by the deprecation policy, so upgrading from 2.2 should be seamless, despite the tweaks to the GCBV implementation.
jspiral 13y ago
I am fairly fluent with django class based views and tastypie, but i can't help but feel this sort of OO design has a painful learning curve. you basically need to dig through the stack of classes, mixins, etc pretty comprehensively to get a sense of how everything fits together. once you understand the flow, it's fine. But I find myself wishing there was a map (and one embodied in the code, not external documentation). Does anyone recognize this feeling and if so do you have any thoughts?
- ptgloden 13y ago
  http://ccbv.co.uk/ http://ccbv.co.uk/ That site helped a lot when I was first getting the gist of CBVs. Browsing Django's source for the views was surprisingly unpainful, and doing that was aided by iPython's introspection capabilities (typing ?? after an object will show you the source of the class).
  - jspiral 13y ago
    wow, thanks for posting this! Very impressive resource. I was trying to speak more to the general challenge of learning this sort of OO system (I pretty much learned class based views by reading the code already), but I'm happy that you shared this, I will pass it on to others.

103 points by tomchristie 13y ago

What's with the nav box completely blocking the document? http://cl.ly/OnPN http://cl.ly/OnPN Running Chrome 28.0.1496.0 dev

tomchristie 13y ago
Note sure. I seem to be able to replicate that if the browser window is exactly 727 pixels wide, but otherwise everything displays just fine for me on Chrome 26.0.1410.65. Will look into it later. Edit: Are you seeing this for all browser widths, or just specific ranges?
- davis_m 13y ago
  I took a quick video of it on my machine: OSX 10.8.3, Chrome Canary Version 28.0.1499.0 canary. It doesn't happen on any other browser on my machine (Vanilla Chrome, Firefox, FirefoxNightly) http://screencast.com/t/2DOssUNcJrGt http://screencast.com/t/2DOssUNcJrGt
  - tomchristie 13y ago
    Thanks, appreciated.
    - raimondious 13y ago
      While you're in there, there's a conflict in the content of the tutorial, at the end of the URLs section: http://django-rest-framework.org/tutorial/quickstart.html http://django-rest-framework.org/tutorial/quickstart.html
      - tomchristie 13y ago
        Ooops. Fixed now - thank you!

woakas 13y ago

awesome thanks :)

ditados 13y ago

Anyone care to weigh in about using this vs., say, TastyPie?

OMBUG 13y ago
Last I tried this (2.1?) it took a hell of a lot more boilerplate than TastyPie, and I had a few problems that necessitated changing the source a bit. But maybe I was using it wrong (didn't spend a huge amount of time with it). The auto generated web interface is nice though.
- antihero 13y ago
  Personally I find it much more powerful and organised than TastyPie, and you can use it for much more basic stuff. You don't actually have to do REST at all. Regarding the boilerplate - IIRC the tutorial starts you off with lots of boilerplate then shows you how to refactor it so it is not needed.
- tomchristie 13y ago
  Author here... The boilerplate comment is definitely valid, and is pretty much what this release was intended to address. We've now introduced ViewSets (an extension of class based views that is similar to Rail's controllers) and Routers, which make it super quick and easy to get your API up and running. The updated README should give you a good idea how simple the APIs can be now: https://github.com/tomchristie/django-rest-framework https://github.com/tomchristie/django-rest-framework I get the impression that what TastyPie does really well is convention-over-configuration - making a bunch of really sensible design decisions on your behalf. What (I hope) REST framework does really well is staying close to Django's conventions, and being easy to customize all the way through, plus of course the browseable API. Either way, there's certainly plenty of folks happy with both frameworks.
  - gtaylor 13y ago
    I'll take boilerplate over magic any day. The thing that irked me the most about TastyPie was the magic and lack of obvious understanding of what was happening under the hood (without source diving). The Zen of Python has something to say about this.

lefrancaiz 13y ago

This is great stuff. The viewsets are about to save me lots of repeated code!

AUmrysh 13y ago

Using 2.1 of this framework and an HBase database, we've been able to reduce load times for data in one of our applications from about 30 seconds down to less than 1. Arguably, this had a lot to do with HBase, but rest-framework is actually really nice and seems to work well in regards to performance.

jeffheard 13y ago

Can anyone comment on DRF's relationship to GeoDjango and whether it's pretty seamless to work with GeoJSON vs. WKT?

tomchristie 13y ago
You might want to take a look at this: https://github.com/mjumbewu/django-rest-framework-gis https://github.com/mjumbewu/django-rest-framework-gis

csmatt 13y ago

When I found this for http://www.socialocale.com http://www.socialocale.com it was a godsend! It made the weird database operations a breeze when working with third-party libs like Userena. It also gave me a concise, modular way to get/put information. If your project is complex, I feel like the Django Rest Framework will be by your side the whole way. It's very well thought out and nicely documented.

mattdeboard 13y ago

I feel very comfortable with Tastypie, and have pretty well internalized its API. I've got most custom code down to muscle memory. Because of this I don't feel constrained by Tastypie at all. That said it is very "Django"-y, meaning it's got a high level of abstraction, very opinionated but provides hooks for everything. It's also pays a huge amount of attention to testing. All that aside I did evaluate DRF for my last project. Tastypie's Django 1.5 support didn't exist, it had some weird interaction issues with our database setup, and it has a huge amount of outstanding issues & pull requests. I spent like 2 days working with DRF and it felt clumsy for me (read: not objectively clumsy, I was just used to thinking about exposing data to a hypermedia API in a particular way). Honestly I just got annoyed by the CBV part. I know some people love them and I'm sure they're great and all, just wasn't for me. edit: frankly they're doing the same thing, they're both well-written and -maintained. It's just about which API you prefer to work with.

tomchristie 13y ago
> Honestly I just got annoyed by the CBV part. There's a bunch of things in 2.3 that should make working with the CBVs a much more pleasant experience. * There's no longer any inheritance from Django's GCBV machinery, specifically SingleObjectMixin, and MultipleObjectMixin. The base class was simple enough that it wasn't really necessary. That means no more browsing across multiple codebases, and less class hierarchy to think about. * Previously there were three base classes, now there's just a single simplified GenericAPIView. * Several attributes and methods have been moved to pending deprecation or refactored and simplified. * Using ViewSets means less verbose, repeated view code and easier URL configuration. Additionally, all the changes are covered by the deprecation policy, so upgrading from 2.2 should be seamless, despite the tweaks to the GCBV implementation.

jspiral 13y ago

I am fairly fluent with django class based views and tastypie, but i can't help but feel this sort of OO design has a painful learning curve. you basically need to dig through the stack of classes, mixins, etc pretty comprehensively to get a sense of how everything fits together. once you understand the flow, it's fine. But I find myself wishing there was a map (and one embodied in the code, not external documentation). Does anyone recognize this feeling and if so do you have any thoughts?

ptgloden 13y ago
http://ccbv.co.uk/ http://ccbv.co.uk/ That site helped a lot when I was first getting the gist of CBVs. Browsing Django's source for the views was surprisingly unpainful, and doing that was aided by iPython's introspection capabilities (typing ?? after an object will show you the source of the class).
- jspiral 13y ago
  wow, thanks for posting this! Very impressive resource. I was trying to speak more to the general challenge of learning this sort of OO system (I pretty much learned class based views by reading the code already), but I'm happy that you shared this, I will pass it on to others.