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.
It's based on Tastypie, but features a complete Resource re-design that moves serialization and validation out of the Resource. The power of a REST framework w\ the flexibility of plain old Django views.
Two companies are using it in production and a few more are evaluating it. If you love-hate TastyPie you might like it.
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.
It's still not clear how the project will do without its original maintainer going forward. I don't bring this up as damning evidence against TastyPie, but it is something to consider. Some projects achieve that critical mass where life continues after the original maintainer steps out, but enough time hasn't elapsed to see how it will play out in this case.
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'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.
The ability in 2.3 to use multiple filter backends is partly intended to address queryset permissions adequately. It means you can setup a filter backend to deal with any permissions-based filtering, while still including client-determined field filtering/searching etc...
Nice, I didn't recognize you could use multiple default filter backends glancing at the 2.3 documentation. That would provide a means of addressing the main concern - creating a reusable object that could be applied to any api view that filters the queryset in a predefined way (eg: limit the queryset to objects owned by the current user). Another point for DRF.
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 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:
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.
The boilerplate was exactly why I went with Tasty-Pie recently, but seeing some of the updates, I might have to revisit that decision. Your documentation is great, btw.
Side note -- the updated urls.py example in the README.md references "views.UserViewSet" but in the context of the example should just be "UserViewSet"... I think. I sent a pull request - ignore if I had it all wrong.
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.
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.
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.
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.
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?
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)
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?
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).
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.
When I found this for 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.
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.
