The Rest Framework is a lot more flexible and just don't get into your way when you need your API to do anything else than exposing CRUD operations.

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.

We looked at and started playing with TastyPie over at Pathwright, but ultimately found that it was very difficult to customize to our needs (mostly with respect to custom API resources, custom filtering, and very fine-grained permissions based on a number of factors). The documentation isn't organized very well, and at the time (a few months ago), it appeared that development had stalled.

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.

I'm actively using both frameworks on separate projects and have roughly 1 year of experience with Tastypie and 2 months of experience with DRF. Both have strengths and weaknesses with very similar feature sets, although I personally prefer DRF, backed up by my choice to use it over Tastypie when starting a new project 2 months ago.

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.

Django REST framework inherits its Views from Django's Class-Based Views. If your app is using CBVs elsewhere, it is one less interface to have to get familiar with. When I need to do something a little advanced the familiar methods get(), post(), dispatch(), get_queryset(), etc are present. Also, most Mixins for Django's CBVs work fine with Django REST framework's Views. Django REST framework separates its logic into two main classes Serializers and Views, compare to Django TastyPie which combines these concepts into a class called a Resource. A Resource also combines what is a ListAPIView and RetrieveAPIView in Django Rest framework, but having them seperate can let you do things like return different model fields for the ListAPIView verus the RetrieveAPIView. Django REST framework's standout feature is the browsable API, which lets explore the API from your browser.

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.

I tried all rest frameworks I could find for both Django and Flask - for me DRF is the cleanest.

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

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.