Question

Pourquoi utiliser un sur l'autre, pour exposer une API pour votre application Django?

http://pypi.python.org/pypi/djangorestframework/

http://pypi.python.org/pypi/django-tastypie

Était-ce utile?

La solution

Comme l'auteur de django-repos-cadre, j'ai un parti pris évident;) mais mon opinion, espérons-assez-objective sur c'est quelque chose comme:

TastyPie

  • Torsten note, vous n'allez pas vous tromper avec quelque chose écrit par les mêmes coups d'oeil que l'impressionnant django-botte de foin . D'après ce que j'ai vu sur leur liste de diffusion Daniel Lindsey et al sont super utiles et Tastypie est stable, complet et bien documenté
  • Excelle en vous donnant un ensemble raisonnable de comportement par défaut et de la construction d'une API avec ce style incroyablement facile.

framework Django REST

  • vous donne HTML peut parcourir, API autodescriptifs. (EG, voir le tutoriel API .) Être capable de naviguer et d'interagir avec l'API directement dans le navigateur est une grande victoire de la facilité d'utilisation.
  • Essaye de rester près de idiomes Django tout au long - construit sur des vues sur la base de la classe de Django, etc ... (Alors que TastyPie est venu avant existait CBV de Django, donc l'utilise sa propre implémentation de vues à base de classe)
  • Je me plais à penser que l'architecture sous-jacente est assez bien construit, découplé etc ...

Dans tous les cas, les deux sont bons. Je qualifierais probablement Tastypie que de vous donner un ensemble raisonnable de défaut de la boîte, et le cadre REST comme étant très bien découplé et flexible. Si vous avez l'intention d'investir beaucoup de temps dans l'API, je recommande def la navigation à travers les documents et codebase de chacun et essayer d'obtenir une idée de ce qui vous convient le plus.

De toute évidence, il y a aussi Pourquoi TastyPie? section README, et le 'cadre REST 3' .

Voir le blog de Daniel Greenfeld également sur Le choix d'un cadre de l'API pour Django , à partir de mai 2012 (à noter que c'était encore quelques mois avant le grand cadre REST 2.0 release).

En outre quelques discussions sur Reddit avec les gens posent cette même question, décembre 2013 et Juillet 2013 .

Autres conseils

Les deux sont de bons choix.

Pour les filtres, tastypie est plus puissant hors-the-box. Si vous avez une vue qui expose un modèle, vous pouvez faire des filtres d'inégalité de style Django:

http://www.example.com/api/person?age__gt=30

ou ou des requêtes:

http://www.example.com/api/mymodel?language__in=en&language__in=fr

ceux-ci sont possibles avec djangorestframework, mais vous devez les filtres écriture personnalisés pour chaque modèle.

Pour retraçage, j'ai été plus impressionné par django-repos-cadre. Tastypie tente de courrier électronique settings.ADMINS sur des exceptions lorsque DEBUG = False. Lorsque DEBUG = True, le message d'erreur par défaut est sérialisé JSON , ce qui est plus difficile à lire.

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.

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.

Well, Tastypie and DRF both are excellent choices. You simply can’t go wrong with either of them. (I haven’t worked on Piston ever; and its kind of not trending anymore now a days so won’t / can’t comment on it. Taken for Granted.). In my humble opinion: Choice should be made on yours (and your tech team’s) skills, knowledge and capabilities. Rather than on what TastyPie and DRF offers, unless off-course you are building something really big like Quora, Facebook or Google.

Personally, I ended up starting working first on TastyPie at a time when I didn’t even know django properly. It all made sense at that time, only knowing REST and HTTP very well but with almost no or little knowledge about django. Because my only intention was to build RESTful APIs in no time which were to be consumed in mobile devices. So if you are just like ‘I happen to be at that time called django-new-bie’, Don’t think more go for TastyPie.

But if you have many years of experience working with Django, knows it inside out and very comfortable using advanced concepts (like Class Based Views, Forms, Model Validator, QuerySet, Manager and Model Instances and how all they interact with one another), **go for DRF. **DFR is bases on django’s class based views. DRF is idiomatic django. Its like you are writing model forms, validators etc. (Well, idiomatic django is no where near to idiomatic python. If you are python expert but have no experience with Django then you might be having hard time initially fit into idiomatic django philosophy and for that matter DRF as well). DRF comes with lots of inbuilt magic methods just like django. If you love the django magical methods and philosophy **DRF **is just for you.

Now, just to answer the exact question:

Tastypie:

Advantages:

  1. Easy to get started with and provide basic functionalities OOB (out of the box)
  2. Most of the time you won’t be dealing with Advanced Django concepts like CBVs, Forms etc
  3. More readable code and less of magic!
  4. If your models are NON-ORM, go for it.

Disadvantages:

  1. Doesn’t strictly follow idiomatic Django (mind well python and django’s philosophies are quite different)
  2. Probably bit tough to customize APIs once you go big
  3. No O-Auth

DRF:

  1. Follow idiomatic django. (If you know django inside out, and very comfortable with CBV, Forms etc without any doubt go for it)
  2. Provides out of the box REST functionality using ModelViewSets. At the same time, provides greater control for customization using CustomSerializer, APIView, GenericViews etc.
  3. Better authentication. Easier to write custom permission classes. Work very well and importantly very easy to make it work with 3rd party libraries and OAuth. DJANGO-REST-AUTH is worth mentioning LIBRARY for Auth/SocialAuthentication/Registration. (https://github.com/Tivix/django-rest-auth)

Disadvantages:

  1. If you don’t know Django very well, don’t go for this.
  2. Magic! Some time very hard to understand magic. Because its been written on top of django’s CBV which are in turn quite complex in nature. (https://code.djangoproject.com/ticket/6735)
  3. Has steep learning curve.

Personally what would I use in my next project?

  • Now, I am no more a fan of MAGIC and Out-of-box functionalities. Because all they come at a *great cost. * Assuming I have all choices and control over project time and budget, I would start with something light weight like RESTLess (https://github.com/toastdriven/restless) (created by the creator of TastyPie and django-haystack (http://haystacksearch.org/)). And for the same matter probably/definately choose the lightweight web framework like Flask.

  • But why? - More readable, simple and manageable idiomatic python (aka pythonic) code. Though more code but eventually provide great flexibility and customization.

    • Explicit is better than implicit.
    • Simple is better than complex.
    • Complex is better than complicated.
    • Flat is better than nested.
    • Sparse is better than dense.
    • Readability counts.
    • Special cases aren't special enough to break the rules.

What if you have only no choice but Django and one of TastyPie and DRF?

  • Now, knowing the Django reasonably well, I will go with **DRF. **
  • Why? - idiomatic djagno! (I don’t love it though). Better OAuth and 3rd party integration (django-rest-auth is my favorite).

Then why you chose the DRF/TastyPie at first place?

  • Mostly I have worked with startups and small firms, which are tight on budget and time; and need to deliver something quick and usable. Django serve this purpose very well. (I am not at all saying that django is not scalable. There are websites like Quora, Disquss, Youtube etc run on it. But all it require time and more then average skills)

I hope, it will help you to take better decision.

Other references - 1. The State of Tastypie (http://toastdriven.com/blog/2014/may/23/state-tastypie/) 2. What are the differences between django-tastypie and djangorestframework? (What are the differences between django-tastypie and djangorestframework?)

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.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top