Django REST framework 2.3 released: ViewSets and Routers

The whole design of DRF makes a lot more sense for my use cases.

TastyPie provides you with Resources that do everything from accepting and dispatching methods, querying db, authentication and authorization to parsing an serializing data. If you want to modify one puzzle you have to redefine the resource.

In DRF the separation between request processing, data serialization/deserialization, rendering and other elements is more clear.

API endpoints are just views that are based on Django class-based views so you should already know how to customize them, do queries and use mixins. Serializers perform data validation (similar to forms, but can handle collections and relations) and conversion between objects and native Python datatypes. They can also be reused in multiple views or for nested relations. Other components are pluggable so you can specify parsers, renderers and auth backends for the whole API or for just a particular view.

The Rest Framework just feels right and works well when you need to do any sort of customization. On top of that you get a very detailed documentation and a browsable API.

TastyPie served me well for a long time and I'm very thankful to the developers, but I find DRF to better suit my needs.

After getting pretty frustrated with TastyPie, we gave rest-framework a try as a last resort before we'd consider doing our own thing. So far, we have found rest-framework to be a whole lot more readable, much more actively maintained, much easier to get help for, and much easier to customize permissions and queryset filtering for.

To us, this ended up being a no-brainer. rest-framework has less magic, it is less complicated, it was easier for us to customize, and the organization of the documentation makes more sense.

But, as with most things, YMMV. We really like rest-framework, but don't take my word for it.

Tastypie has a rather monolithic structure (most of the logic is wrapped in a single resource object) that passes responsibility from function to function. I find the code hard to read and mentally compartmentalize the various components. It does a great job providing basic functionality out of the box, but as soon as you start to do anything complex you will find yourself repeatedly digging through Tastypie source code to track down behavior. Tastypie approach to URLs is also rather limiting.

DRF uses Django class based views and generally follows Django's design patterns. I find the code much easier to understand and more inline with the direction Django is heading. The module class structure makes it much easier to build reusable components. One downside with DRF is their permissions system, it has a rather large oversight for multiple object permissions. DRF completely excludes the queryset from the permission decision which leads to some terrible workarounds (I'm not sure how you can make an informed permission decision on a set of objects without access to the set of objects themselves).

The documentation and community on both is rather strong, although there is more information on Tastypie as they've been around longer. As a point of reference, Tastypie has ~750 questions on stackoverflow vs 153 for django-rest-framework. Both are actively maintained, but Tastypie's design architecture handcuffs it's ability to move forward.

tl;dr; My $0.02 - Tastypie was the standard, DRF is becoming the standard. I would personally choose DRF over Tastypie for any future project.

TastyPie is more "complete" than Django REST framework. It has URL routing, which makes setting up an API namespace in your URLs super simple. It has queryset filtering from the URL (e.g. /articles/?author=1). Django REST framework relies on another third-party app to do this. It also has caching built-in. I find it's internal interface a little bit more confusing the Django REST framework's, but that could be that I am just more familiar with Django CBVs.

The standard html interface for it (and content type handling) are definitely the best of all of them. You can get a very complete api up and running with not much effort.

The documentation is really nice and clear and if you get stuck just take a look at the code - it's very easy to follow. You should look at it anyway, it's nice code to read through.

My only complaint is that it's not built for Flask :)

The auto generated web interface is nice though.

Edit: Are you seeing this for all browser widths, or just specific ranges?

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.

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).