Quali sono le differenze tra django-tastypie e djangorestframework? [chiuso]


157

Perché dovresti usarne uno sopra l'altro per esporre un'API per la tua app Django?

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

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

Risposte:


206

Come autore di django-rest-framework, ho un evidente pregiudizio;) ma la mia opinione, si spera, abbastanza obiettiva su questo, è qualcosa del tipo:

TastyPie

  • Come notato da Torsten, non sbaglierai molto con qualcosa scritto dagli stessi sbirciati del fantastico pagliaio da django . Da quello che ho visto nella loro mailing list Daniel Lindsey et al. Sono di grande aiuto e Tastypie è stabile, completo e ben documentato
  • Eccelle nel darti una serie ragionevole di comportamenti predefiniti e nel rendere incredibilmente facile la creazione di un'API con quello stile.

Quadro Django REST

  • Ti offre API auto-descrittive che possono essere esplorate in HTML. (Ad esempio, consultare l' API tutorial .) Essere in grado di navigare e interagire con l'API direttamente nel browser è una grande vittoria di usabilità.
  • Cerca di stare vicino ai modi di dire di Django per tutto il tempo - costruito sulla base delle viste di classe di Django, ecc ... (Considerando che TastyPie è arrivato prima che esistessero i CBV di Django, quindi usa l'implementazione delle viste basata su classi)
  • Mi piacerebbe pensare che l'architettura sottostante sia piuttosto ben costruita, disaccoppiata ecc ...

In ogni caso, entrambi sono buoni. Probabilmente definirei Tastypie come una serie ragionevole di impostazioni predefinite e il framework REST è molto ben disaccoppiato e flessibile. Se stai pensando di investire molto tempo nell'API, ti consiglio di sfogliare i documenti e la base di codice di ciascuno e cercare di avere un'idea di quello che ti si addice di più.

Ovviamente, c'è anche il 'Why TastyPie?' sezione in esso è README e il 'REST framework 3' .

Vedi anche il post sul blog di Daniel Greenfeld sulla scelta di un framework API per Django , a partire da maggio 2012 (vale la pena notare che questo era ancora pochi mesi prima della grande versione REST framework 2.0).

Anche un paio di thread su Reddit con la gente che chiede la stessa domanda, da dicembre 2013 e luglio 2013 .


7
A proposito, abbiamo usato Django-rest-framework per un grande progetto, ed è fantastico! Ho provato a provare Gypypie per una settimana in anticipo e non ho rimpianti di andare con DRF. Purtroppo la documentazione non è all'altezza del codice e del quadro stesso, ma a parte questo, pura felicità.
Ben Roberts,

Grandi cose, grazie Ben. E sì, il tuo punto è. la documentazione è decisamente corretta. Progettando di affrontarlo!
Tom Christie,

Il link al video "i miei discorsi lampo da DjangoCon su django-rest-framework" è morto!
Mutante,

1
@Mutant - Grazie, il sito djangocon.eu 2011 è ora morto, ma ho collegato direttamente al video su blip.tv.
Tom Christie,

@TomChristie Il link a blip.tv è morto ora! È questo il video corretto?
Kevin

19

Entrambe sono buone scelte.

Per i filtri, tastypie è più potente e pronto all'uso. Se hai una vista che espone un modello, puoi fare i filtri di disuguaglianza in stile Django:

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

o richieste OR:

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

questi sono possibili con djangorestframework, ma devi scrivere filtri personalizzati per ogni modello.

Per quanto riguarda i traceback, sono stato più colpito da django-rest-framework. Tastypie prova a inviare e-mail settings.ADMINSsu eccezioni quando DEBUG = False. Quando DEBUG = True, il messaggio di errore predefinito è JSON serializzato , che è più difficile da leggere.


8
Non è necessario scrivere filtri personalizzati per questo in Django REST Framework. Hai solo bisogno di utilizzare il fornito DjangoFilterBackendcome documentato dal framework REST qui: django-rest-framework.org/api-guide/filtering#api-guide
monokrome

13

EDIT Risposta obsoleta, tastypie non è più davvero mantenuto. Usa il framework Django REST se devi scegliere un framework per eseguire REST.

Per una panoramica delle effettive differenze tra i due è necessario leggere la loro documentazione. Sono entrambi più o meno completi e abbastanza maturi.

Personalmente tendo a provare la gastronomia. Sembra essere più facile da configurare. È fatto dalle stesse persone che hanno creato il pagliaio django che è fantastico e secondo i pacchetti django è usato più del framework Django REST.


2
La documentazione non è affatto una buona "panoramica delle effettive differenze tra loro".
Monokrome,

I -1 questo perché è notevolmente obsoleto e c'è ormai un errore di fatto: DRF è ora molto più utilizzato di TastyPie. Detto questo, l'autore ha incluso il link ai pacchetti django, è una risposta di alta qualità.
texnic,

1
Sulla base della storia e dei problemi di Github che sono stati risolti nel 2018, sembrerebbe che TastyPie sia ancora mantenuto.
Sushil,

Tastypie è supportato per django 1.11, questo è confortante per la considerazione dei progetti futuri. django-tastypie.readthedocs.io/en/latest/…
elsadek

5

Vale la pena notare che da quando è stato chiesto per la prima volta DRF è andato sempre più rafforzando.

È il più attivo dei due su github (sia in termini di commit, stelle, forchette e collaboratori)

DRF ha il supporto OAuth 2 e l'API navigabile.

Onestamente per me quell'ultima caratteristica è l'assassino. Essere in grado di indirizzare tutti i miei sviluppatori front-end all'API navigabile quando non sono sicuri di come funzioni qualcosa e dire 'Vai a giocare; scoprire 'è fantastico.

Non da ultimo perché significa che riescono a capirlo alle loro condizioni e sanno che l'API fa davvero, assolutamente, ciò che la "documentazione" dice che fa. Nel mondo dell'integrazione con le API, questo fatto da solo rende DRF il framework da battere.


Mi chiedo se django-tastypie-swaggercolma questa lacuna?
Victor Sergienko,

2

Bene, Tastypie e DRF sono entrambi eccellenti scelte. Semplicemente non puoi sbagliare con nessuno dei due. (Non ho mai lavorato su Piston; e il suo tipo di tendenza non è più al giorno d'oggi, quindi non posso / non posso commentarlo. Preso per scontato.). A mio modesto parere: la scelta dovrebbe essere fatta sulle tue abilità, conoscenze e capacità (e del tuo team tecnico). Piuttosto che su ciò che offre TastyPie e DRF, a meno che tu non stia costruendo qualcosa di veramente grande come Quora, Facebook o Google.

Personalmente, ho finito per iniziare a lavorare prima su TastyPie in un momento in cui non conoscevo nemmeno correttamente il django. Tutto aveva senso in quel momento, conoscendo solo REST e HTTP molto bene ma con una conoscenza quasi nulla o scarsa di django. Perché la mia unica intenzione era quella di creare in poco tempo API RESTful da consumare nei dispositivi mobili. Quindi, se sei come 'Mi capita di essere in quel momento chiamato django-new-bie', non pensare di più per TastyPie.

Ma se hai molti anni di esperienza di lavoro con Django, lo conosci a fondo e ti senti molto a tuo agio nell'utilizzare concetti avanzati (come viste basate su classi, moduli, validatore di modelli, QuerySet, Manager e istanze del modello e come interagiscono tra loro), * * scegli DRF. ** DFR si basa su viste basate sulla classe di django. DRF è un django idiomatico. È come se stessi scrivendo modelli di modelli, validatori, ecc. (Beh, il django idiomatico non è vicino al pitone idiomatico. Se sei un esperto di pitone ma non hai esperienza con Django, allora potresti avere difficoltà inizialmente ad adattarti alla filosofia del django idiomatico e per importa anche DRF). DRF viene fornito con molti metodi magici integrati proprio come il django. Se ami i metodi e la filosofia magici del django ** DRF ** è solo per te.

Ora, solo per rispondere alla domanda esatta:

Tastypie:

vantaggi:

  1. Facile da iniziare e fornire funzionalità di base OOB (pronto all'uso)
  2. Il più delle volte non avrai a che fare con concetti avanzati di Django come CBV, moduli ecc
  3. Codice più leggibile e meno magia!
  4. Se i tuoi modelli sono NON-ORM, provaci.

svantaggi:

  1. Non segue rigorosamente Django idiomatico (mente bene le filosofie di pitone e django sono abbastanza diverse)
  2. Probabilmente un po 'difficile personalizzare le API una volta che sei grande
  3. No O-Auth

DRF:

  1. Segui il django idiomatico. (Se conosci django alla rovescia, e sei molto a tuo agio con CBV, Forms ecc., Senza dubbio provaci)
  2. Fornisce funzionalità REST predefinite utilizzando ModelViewSets. Allo stesso tempo, offre un maggiore controllo per la personalizzazione utilizzando CustomSerializer, APIView, GenericViews ecc.
  3. Migliore autenticazione. È più facile scrivere classi di autorizzazione personalizzate. Funziona molto bene e, soprattutto, molto semplice per farlo funzionare con librerie di terze parti e OAuth. DJANGO-REST-AUTH merita di essere menzionato LIBRARY per Auth / SocialAuthentication / Registration. ( https://github.com/Tivix/django-rest-auth )

svantaggi:

  1. Se non conosci molto bene Django, non andare per questo.
  2. Magia! Qualche volta molto difficile capire la magia. Perché è stato scritto in cima al CBV di Django che sono a loro volta abbastanza complessi in natura. ( https://code.djangoproject.com/ticket/6735 )
  3. Ha una ripida curva di apprendimento.

Personalmente cosa avrei usato nel mio prossimo progetto?

  • Ora, non sono più un fan delle funzionalità MAGIC e out-of-box. Perché tutto ciò ha un * grande costo. * Supponendo di avere tutte le scelte e il controllo sui tempi e sul budget del progetto, inizierei con qualcosa di leggero come RESTLess ( https://github.com/toastdriven/restless ) (creato dal creatore di TastyPie e django-haystack ( http: //haystacksearch.org/ )). E per lo stesso motivo probabilmente / sicuramente scegli il framework leggero come Flask.

  • Ma perché? - Codice pitone idiomatico (aka pythonic) più leggibile, semplice e gestibile. Anche se più codice, ma alla fine offre grande flessibilità e personalizzazione.

    • Esplicito è meglio che implicito.
    • Semplice è meglio di complesso.
    • Complesso è meglio che complicato.
    • Flat è meglio di nidificato.
    • Sparse è meglio che denso.
    • La leggibilità conta.
    • I casi speciali non sono abbastanza speciali da infrangere le regole.

E se non avessi altra scelta che Django e uno di TastyPie e DRF?

  • Ora, conoscendo il Django abbastanza bene, andrò con ** DRF. **
  • Perché? - idiomatico djagno! (Non mi piace però). Migliore integrazione OAuth e di terze parti (django-rest-auth è il mio preferito).

Allora perché hai scelto DRF / TastyPie al primo posto?

  • Principalmente ho lavorato con start-up e piccole aziende, che sono attente al budget e al tempo; e ho bisogno di fornire qualcosa di rapido e utilizzabile. Django serve molto bene a questo scopo. (Non sto affatto dicendo che il django non è scalabile. Ci sono siti web come Quora, Disquss, Youtube, ecc. Corrono su di esso. Ma tutto ciò richiede tempo e più di abilità nella media)

Spero che ti aiuterà a prendere una decisione migliore.

Altri riferimenti - 1. The State of Tastypie ( http://toastdriven.com/blog/2014/may/23/state-tastypie/ ) 2. Quali sono le differenze tra django-tastypie e djangorestframework? ( Quali sono le differenze tra django-tastypie e djangorestframework? )


1

Avendo usato entrambi, una cosa che mi è piaciuta (preferita) di Django Rest Framwork è che è molto coerente con Django.

La scrittura di serializzatori di modelli è molto simile alla scrittura di moduli modello. Le viste generiche integrate sono molto simili alle viste generiche di Django per HTML.


1

Django-tastypie non è più gestito dal suo creatore originale e ha creato un suo nuovo framework leggero.

Al momento dovresti usare django-rest-framework con django se vuoi esporre la tua API.

Le grandi aziende lo stanno usando. django-rest-framework è un membro principale del team di django e ottiene finanziamenti per mantenere il django-rest-framework.

django-rest-framework ha anche un numero enorme di pacchetti 3rd art sempre crescenti che ti aiuteranno a costruire le tue API più facilmente con meno problemi.

Alcune parti del drf verranno anche unite nel django vero e proprio.

drf fornisce modelli e strumenti migliori rispetto a django-tastypie.

In breve, è ben progettato, ben mantenuto, finanziato, offre enormi app di terze parti, considerate affidabili da grandi organizzazioni, più semplici e meno eccitanti rispetto a tastypie.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.