Pourquoi utiliseriez-vous l'un sur l'autre, pour exposer une API pour votre application Django?
Pourquoi utiliseriez-vous l'un sur l'autre, pour exposer une API pour votre application Django?
Réponses:
En tant qu'auteur de django-rest-framework, j'ai un biais évident;) mais mon opinion, espérons-le, assez objective à ce sujet est quelque chose comme:
En tout cas, les deux sont bons. Je caractériserais probablement Tastypie comme vous donnant un ensemble raisonnable de valeurs par défaut prêtes à l'emploi, et le cadre REST comme étant très bien découplé et flexible. Si vous prévoyez d'investir beaucoup de temps dans l'API, je vous recommande vivement de parcourir les documents et la base de code de chacun et d'essayer de vous faire une idée de ce qui vous convient le mieux.
De toute évidence, il y a aussi le «Pourquoi TastyPie? dans son fichier README, et le 'REST framework 3' .
Voir également l'article de blog de Daniel Greenfeld sur le choix d'un framework d'API pour Django , de mai 2012 (à noter que c'était encore quelques mois avant la sortie du grand framework REST 2.0).
Aussi quelques discussions sur Reddit avec les gens posent cette même question, à partir de décembre 2013 et Juillet 2013 .
Les deux sont de bons choix.
Pour les filtres, tastypie est plus puissant prêt à l'emploi. 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 OR requêtes:
http://www.example.com/api/mymodel?language__in=en&language__in=fr
ceux-ci sont possibles avec djangorestframework, mais vous devez écrire des filtres personnalisés pour chaque modèle.
Pour les retraités, j'ai été plus impressionné par django-rest-framework. Tastypie essaie d'envoyer un e-mail settings.ADMINS
sur les exceptions quand DEBUG = False
. Quand DEBUG = True
, le message d'erreur par défaut est JSON sérialisé , qui est plus difficile à lire.
DjangoFilterBackend
tel que documenté par le framework REST ici: django-rest-framework.org/api-guide/filtering#api-guide
EDIT Réponse obsolète, le tastypie n'est plus vraiment maintenu. Utilisez le framework Django REST si vous devez choisir un framework pour effectuer 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 matures.
Personnellement, j'ai tendance à avoir du goût. Cela semble plus facile à mettre en place. Il est fait par les mêmes personnes qui ont créé django-haystack, ce qui est génial et selon django-packages, il est plus utilisé que le framework Django REST.
Il convient de noter que depuis que cela a été demandé pour la première fois, DRF n'a cessé de se renforcer.
C'est le plus actif des deux sur github (à la fois en termes de commits, d'étoiles, de fourchettes et de contributeurs)
DRF prend en charge OAuth 2 et l'API navigable.
Honnêtement pour moi, cette dernière fonctionnalité est le tueur. Pouvoir pointer tous mes développeurs front-end vers l'API navigable lorsqu'ils ne sont pas sûrs du fonctionnement de quelque chose et dire «Allez jouer; découvrir »est fantastique.
Notamment parce que cela signifie qu'ils apprennent à le comprendre selon leurs propres termes et 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 framework à battre.
django-tastypie-swagger
comble cet écart?
Eh bien, Tastypie et DRF sont tous deux d'excellents choix. Vous ne pouvez tout simplement pas vous tromper avec l'un ou l'autre. (Je n'ai jamais travaillé sur Piston; et sa tendance n'est plus à la mode depuis quelques jours, donc je ne peux pas / ne peux pas le commenter. Pris pour acquis.). À mon humble avis: le choix doit être fait sur vos compétences, connaissances et capacités (et celles de votre équipe technique). Plutôt que sur ce que propose TastyPie et DRF, à moins que vous ne construisiez 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 correctement django. Tout cela avait du sens à ce moment-là, ne connaissant que très bien REST et HTTP mais avec presque pas ou peu de connaissances sur django. Parce que ma seule intention était de créer en un rien de temps des API RESTful qui devaient être utilisées dans les appareils mobiles. Donc, si vous êtes juste comme "je m'appelle à ce moment-là django-new-bie", ne pensez plus à TastyPie.
Mais si vous avez de nombreuses années d'expérience de travail avec Django, que vous le connaissez à fond et très à l'aise en utilisant des concepts avancés (comme les vues basées sur les classes, les formulaires, le validateur de modèle, le QuerySet, le gestionnaire et les instances de modèle et comment ils interagissent les uns avec les autres), * * optez pour DRF. ** DFR est basé sur les vues basées sur les classes de django. DRF est un django idiomatique. C'est comme si vous écriviez des modèles de formulaires, des validateurs, etc. qui importent aussi DRF). DRF est livré avec de nombreuses méthodes magiques intégrées, tout comme django. Si vous aimez les méthodes et la philosophie magiques de django, ** DRF ** est fait pour vous.
Maintenant, juste pour répondre à la question exacte:
Tastypie:
Avantages:
Désavantages:
DRF:
Désavantages:
Personnellement, qu'est-ce que j'utiliserais dans mon prochain projet?
Désormais, je ne suis plus fan des fonctionnalités MAGIC et Out-of-box. Parce que tout cela coûte cher. * En supposant que j'ai tous les choix et le contrôle du temps et du budget du projet, je commencerais par quelque chose de léger comme RESTLess ( https://github.com/toastdriven/restless ) (créé par le créateur de TastyPie et django-haystack ( http: //haystacksearch.org/ )). Et pour la même question, choisissez probablement / définitivement le framework Web léger comme Flask.
Mais pourquoi? - Code python idiomatique (aka pythonic) plus lisible, simple et gérable. Bien que plus de code, mais offre finalement une grande flexibilité et personnalisation.
Et si vous n'aviez d'autre choix que Django et l'un des TastyPie et DRF?
Alors pourquoi avez-vous choisi le DRF / TastyPie à la première place?
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 djangorestframework? ( Quelles sont les différences entre django-tastypie et djangorestframework? )
Ayant utilisé les deux, une chose que j'ai aimée (préférée) à propos de Django Rest Framwork est qu'elle est très cohérente avec Django.
L'écriture de sérialiseurs de modèles est très similaire à l'écriture de formulaires modèles. Les vues génériques intégrées sont très similaires aux vues génériques de Django pour HTML.
Django-tastypie n'est plus maintenu par son créateur d'origine et il a créé son propre cadre léger.
À l'heure actuelle, vous devez utiliser django-rest-framework avec django si vous souhaitez exposer votre API.
Les grandes entreprises l'utilisent. django-rest-framework est un membre principal de l'équipe django et il obtient des fonds pour maintenir django-rest-framework.
django-rest-framework a également un grand nombre de packages 3ème arty en constante augmentation, ce qui vous aidera à créer plus facilement vos API avec moins de tracas.
Une partie de drf sera également fusionnée dans django proprement dit.
drf fournit plus de meilleurs modèles et outils que django-tastypie.
En bref, il est bien conçu, bien entretenu, financé, fournit d'énormes applications tierces, auxquelles les grandes organisations font confiance, plus facile et moins passe-partout, etc.