Quelles sont les différences entre django-tastypie et djangorestfram Framework? [fermé]

Pourquoi utiliser l'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

141
demandé sur michel.iamit 2011-09-05 06:04:12

7 réponses

en tant qu'auteur de django-rest-framework, j'ai un parti pris évident ;) mais mon opinion-avec un peu de chance-assez-objective sur ceci est quelque chose comme:

TastyPie

  • comme Torsten l'a noté, vous n'allez pas vous tromper avec quelque chose écrit par les mêmes personnes que le génial django-haystack . De ce que j'ai vu sur leur liste de diffusion Daniel Lindsey et autres sont super-utile, et Tastypie est stable, complet et bien documenté
  • excelle en vous donnant un ensemble raisonnable de comportement par défaut et en rendant la construction D'une API avec ce style incroyablement facile.

Django REST framework

  • vous donne les API auto-descriptives de navigation HTML. (EG, voir le tutorial API .) Pouvoir naviguer et interagir avec L'API directement dans le navigateur est un gain important en termes de convivialité.
  • Essaie de rester proche des idiomes Django tout au long - construit sur le haut de la classe Django vues basées, etc... (Alors que TastyPie est arrivé avant que les CBVs de Django existent, il utilise donc sa propre mise en œuvre de vues basées sur la classe)
  • j'aimerais penser que l'architecture sous-jacente est assez bien construite, découplée, etc...

dans tous les cas, les deux sont bons. Je caractériserais probablement Tastypie comme vous donnant un ensemble raisonnable de valeurs par défaut hors de la boîte, et REST cadre comme étant très bien découplé et souple. Si vous prévoyez d'investir beaucoup de temps dans L'API, je vous recommande de parcourir la base docs & codebase de chacun et d'essayer de vous faire une idée de ce qui vous convient le plus.

évidemment, il y a aussi le pourquoi TastyPie?'"151970920 de la section" dans README, et le de REPOS cadre 2 annonce' .

Voir Aussi Le billet du blog de Daniel Greenfeld sur le Choix d'une API cadre pour Django , à partir de Mai 2012 (à noter que ce était encore quelques mois avant le grand REPOS cadre de la version 2.0).

aussi un couple de fils sur Reddit avec des gens qui posent cette même question, de déc 2013 et juillet 2013 .

Dernière mise à jour de Février 2014

191
répondu Tom Christie 2014-02-01 14:14:00

les deux sont de bons choix.

pour les filtres, tastypie est plus puissant out-of-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 de la OU des requêtes:

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

ceux-ci sont possibles avec djangorestfram Framework, mais vous devez écrire des filtres personnalisés pour chaque modèle.

pour tracebacks, j'ai été plus impressionné par django-rest-framework. Tastypie essaie d'envoyer settings.ADMINS par email sur les exceptions quand DEBUG = False . Lorsque DEBUG = True , le message d'erreur par défaut est sérialisé JSON , qui est plus difficile à lire.

19
répondu Wilfred Hughes 2016-02-17 09:22:17

EDIT réponse dépassée, tastypie n'est plus vraiment maintenu. Utilisez Django REST framework si vous devez choisir un framework pour faire REST.

pour un aperçu des différences réelles entre les deux, vous devriez lire leur documentation. Ils sont à la fois plus ou moins complets et assez mûrs.

j'ai personnellement tendance à tastypie. Il semble être plus facile à mettre en place. Il est fait par les mêmes personnes qui créé django-haystack qui est impressionnant et selon django-paquets il est utilisé plus que cadre de repos de Django.

9
répondu Torsten Engelbrecht 2016-10-21 07:05:48

il est intéressant de noter que depuis qu'on lui a demandé pour la première fois, la DRF est passée de la force à la force.

C'est le plus actif des deux sur github (à la fois en termes de commits, étoiles, fourchettes et contributeurs)

DRF a OAuth 2 support et L'API browsable.

honnêtement pour moi ce dernier trait est le tueur. Être capable de pointer tous mes devs front-end vers L'API browsable quand ils ne sont pas sûrs comment quelque chose fonctionne et dire 'Go' de jouer, de trouver out' qui est fantastique.

notamment parce que cela signifie qu'ils arrivent à le comprendre selon leurs propres termes et qu'ils savent que l'API fait vraiment, certainement, absolument ce que la "documentation" dit qu'elle fait. Dans le monde de l'intégration avec les API, CE seul fait fait de DRF le cadre à battre.

5
répondu Tom Manterfield 2015-06-21 22:49:29

ayant utilisé les deux, une chose que j'ai aimé (préféré) à propos de Django Rest Framwork est qu'il est très compatible avec Django.

L'écriture de sérialiseurs de modèle est très similaire à l'écriture de formulaires de modèle. Les vues génériques intégrées sont très similaires aux vues génériques de Django pour HTML.

1
répondu wobbily_col 2016-05-12 13:52:04

Tastypie et DRF sont d'excellents choix. Vous avez simplement ne peut pas aller mal avec l'un d'eux. (Je N'ai pas travaillé sur Piston jamais; et son genre de ne plus tendance maintenant un jour ne sera pas / ne peut pas commenter sur elle. Pris pour acquis.). À mon humble avis: le choix devrait être fait sur vos compétences (et celles de votre équipe technique), vos connaissances et vos capacités. plutôt que sur ce que TastyPie et DRF offre, à moins que hors cours vous construisez quelque chose de vraiment grand comme Quora, Facebook ou Google.

personnellement, j'ai fini par commencer à travailler sur TastyPie à un moment où je ne connaissais même pas django correctement. Tout cela avait du sens à l'époque, ne connaissant que très bien REST et HTTP mais avec presque aucune ou peu de connaissances sur django. Parce que ma seule intention était de construire des API reposantes en un rien de temps qui devaient être consommées dans les appareils mobiles. Donc, si vous êtes comme " j'arrive d'être à l'époque appelé django-nouvelle-bie’, ne pense pas que plus de goût pour TastyPie.

mais si vous avez beaucoup années d'expérience de travail avec Django, sait de l'intérieur et très à l'aise en utilisant des concepts avancés (comme les vues basées sur la classe, les formes, le validateur de modèle, QuerySet, le gestionnaire et les Instances de Modèle et comment tous ils interagissent entre eux), **allez pour DRF. **DFR est basé sur les vues de classe de django. Le DRF est un django idiomatique. C'est comme si tu écrivais des formulaires modèles., les validateurs etc. (Eh bien, Django idiomatique n'est pas très proche de Python idiomatique. Si vous êtes expert en python mais que vous n'avez aucune expérience avec Django, alors vous pourriez avoir du mal à vous intégrer dans la philosophie idiomatique de django et pour cette raison DRF également). DRF est livré avec beaucoup de méthodes magiques intégrées tout comme django. Si vous aimez les méthodes magiques django et la philosophie **DRF **est juste pour vous.

maintenant, juste pour répondre à la question exacte:

Tastypie:

avantages:

  1. Facile à prendre en main et de fournir des fonctionnalités de base OOB (out of the box)
  2. la plupart du temps, vous n'aurez pas affaire à des concepts Django avancés comme les CBVs, les formulaires etc
  3. plus de code lisible et moins de magie!
  4. si vos modèles ne sont pas ORM, allez-y.

inconvénients:

  1. Ne pas suivre strictement idiomatiques Django (l'esprit bien python et django philosophies sont très différentes)
  2. probablement un peu difficile à personnaliser APIs une fois que vous allez grand
  3. No O-Auth

DRF:

  1. suivre Django idiomatique. (Si vous connaissez django à l'intérieur, et très à l'aise avec CBV, des Formes etc ... sans aucun doute aller pour elle)
  2. fournit la fonctionnalité de repos hors de la boîte à l'aide de ModelViewSets. En même temps, fournit un plus grand contrôle pour la personnalisation en utilisant CustomSerializer, APIView, GenericViews etc.
  3. meilleure authentification. Plus facile d'écrire des classes de permission personnalisées. Travailler très bien et surtout très facile à faire fonctionner avec des bibliothèques tierces et OAuth. DJANGO-REST-AUTH vaut bibliothèque de référence pour Auth / social Authentication / Registration. ( https://github.com/Tivix/django-rest-auth )

inconvénients:

  1. si vous ne connaissez pas très bien Django, ne faites pas ça.
  2. de la Magie! Parfois très difficile de comprendre la magie. Parce que son a été écrit sur le dessus de la CBV de django qui sont à leur tour assez complexe dans la nature. ( https://code.djangoproject.com/ticket/6735 )
  3. a une courbe d'apprentissage abrupte.

personnellement, que devrais-je utiliser dans mon prochain projet?

  • maintenant, je ne suis plus un fan de la magie et des fonctionnalités out-of-box. Parce que tout ce qu'ils arrivent à un *grand coût. * En supposant que j'ai tous les choix et le contrôle sur le temps et le budget du projet, je commencerais par quelque chose de léger poids comme agité ( https://github.com/toastdriven/restless ) (créé par le créateur de TastyPie et django-haystack ( ) http://haystacksearch.org / )). Et pour la même question probablement/définitivement choisir le cadre de web léger comme flacon.

  • mais pourquoi? - Code Python (aka pythonic) plus lisible, simple et maniable. Bien que plus de code mais finalement fournir une grande flexibilité et personnalisation.

    • explicite vaut mieux qu'implicite.
    • Simple vaut mieux que complexe.
    • Complexe est mieux que compliqué.
    • plat est mieux que niché.
    • clairsemé est mieux que dense.
    • la lisibilité compte.
    • les cas spéciaux ne sont pas assez spéciaux pour enfreindre les règles.

et si vous N'aviez pas d'autre choix que Django et un de TastyPie et DRF?

  • maintenant, connaissant assez bien le Django, j'irai avec * * DRF. **
  • pourquoi? - djagno idiomatique! (Je n'aime pas bien). Meilleure intégration OAuth et tierce partie (django-rest-auth est mon préféré).

alors pourquoi vous choisir le DRF / TastyPie à la première place?

  • la plupart du temps, j'ai travaillé avec des start-up et des petites entreprises, qui sont serrés sur le budget et le temps; et besoin de fournir quelque chose rapide et utilisable. Django servent très bien cet objectif. (Je ne dis pas du tout que django n'est pas extensible. Il y a des sites comme Quora, Disquss, Youtube, etc. Mais tout cela demande du temps et plus que des compétences moyennes)

j'espère que cela vous aidera à prendre une meilleure décision.

autres références - 1. L'État de Tastypie ( ) http://toastdriven.com/blog/2014/may/23/state-tastypie / ) 2. Quelles sont les différences entre django-tastypie et djangorestfram Framework? ( quelles sont les différences entre django-tastypie et djangorestfram Framework? )

1
répondu Jadav Bheda 2017-05-23 12:26:17

Django-tastypie n'est plus entretenu par son créateur original et il a créé son propre cadre léger.

Actuellement, vous devez utiliser django-rest-framework avec django si vous êtes prêt à exposer votre API.

les grandes entreprises l'utilisent. django-repos-cadre est un membre clé de django équipe et il obtenir du financement pour maintenir django-repos-cadre.

django-repos-cadre ont également énorme nombre de paquets de 3ème arty toujours en croissance aussi qui vous aideront à construire vos API plus facilement avec moins de tracas.

une partie du drf sera également fusionnée dans django proprement dit.

drf fournir de meilleurs modèles et outils que django-tastypie.

en bref, il est bien conçu, bien entretenu, financé, fournir des applications tiers énormes, de confiance par de grandes organisations, plus facile et moins boilerplate etc sur tastypie.

1
répondu auvipy 2016-12-26 13:52:43