Why would you use one over the other, for exposing an API for your Django app?
相关问题
- Django __str__ returned non-string (type NoneType)
- Design RESTful service with multiple ids
- Django & Amazon SES SMTP. Cannot send email
- Axios OPTIONS instead of POST Request. Express Res
- Plain (non-HTML) error pages in REST api
相关文章
- 我用scrapy写了一个蛮简单的爬虫怎么封装成一个api啊
- 后端给前端的API接口是怎么用代码写的
- Profiling Django with PyCharm
- Why doesn't Django enforce my unique_together
- MultiValueDictKeyError in Django admin
- Django/Heroku: FATAL: too many connections for rol
- Convert C# Object to Json Object
- Serialise choice text for IntegerField with choice
As the author of django-rest-framework, I've got an obvious bias ;) but my hopefully-fairly-objective opinion on this is something like:
TastyPie
Django REST framework
In any case, both are good. I would probably characterise Tastypie as giving you a sensible set of defaults out of the box, and REST framework as being very nicely decoupled and flexible. If you're planning on investing a lot of time in the API, I'd def recommend browsing through the docs & codebase of each and trying to get a feel for which suits you more.
Obviously, there's also the 'Why TastyPie?' section in it's README, and the 'REST framework 2 announcement'.
See also Daniel Greenfeld's blog post on Choosing an API framework for Django, from May 2012 (Worth noting that this was still a few months before the big REST framework 2.0 release).
Also a couple of threads on Reddit with folks asking this same question, from Dec 2013 and July 2013.
Last updated Feb 2014
Having used both, one thing that I liked (preferred) about Django Rest Framwork is that is is very consistent with Django.
Writing model serializers is very similar to writing model forms. The built in Generic Views are very similar to Django's generic views for HTML.
Django-tastypie is no longer maintained by it's original creator and he created a new light weight framework of his own.
At present you should use django-rest-framework with django if you are willing to expose your API.
Large corporations are using it. django-rest-framework is a core member of django team and he get funding to maintain django-rest-framework.
django-rest-framework also have huge number of ever growing 3rd arty packages too which will help you build your API's more easily with less hassles.
Some part of drf will also be merged in django proper.
drf provide more better patterns and tools then django-tastypie.
In short it's well designed, well maintained, funded, provide huge 3rd party apps, trusted by large organisations, easier and less boilerplate etc over tastypie.
Both are good choices.
For filters, tastypie is more powerful out-of-the-box. If you have a view that exposes a model, you can do Django-style inequality filters:
or OR queries:
these are possible with djangorestframework, but you have to write custom filters for each model.
For tracebacks, I've been more impressed with django-rest-framework. Tastypie tries to email
settings.ADMINS
on exceptions whenDEBUG = False
. WhenDEBUG = True
, the default error message is serialised JSON, which is harder to read.EDIT Outdated answer, tastypie is not really maintained anymore. Use Django REST framework if you have to choose a framework to do REST.
For an overview about the actual differences between both of them you should read their documentation. They are both more or less complete and quite mature.
I personally tend to tastypie though. It seems to be easier to set it up. It's done from the same people which created django-haystack which is awesome and according to django-packages it is used more than Django REST framework.
It's worth noting that since this was first asked DRF has gone from strength to strength.
It's the more active of the two on github (both in terms of commits, stars, forks and contributors)
DRF has OAuth 2 support and the browsable API.
Honestly for me that last feature is the killer. Being able to point all my front-end devs at the browsable API when they aren't sure how something works and say 'Go play; find out' is fantastic.
Not least because it means they get to understand it on their own terms and know that the API really, definitely, absolutely does what the 'documentation' says it does. In the world of integrating with APIs, that fact alone makes DRF the framework to beat.