Apa perbedaan antara django-tastypie dan djangorestframework? [Tutup]

157

Mengapa Anda menggunakan yang satu di atas yang lain, untuk mengekspos API untuk aplikasi Django Anda?

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

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

penggiling kopi
sumber

Jawaban:

206

Sebagai penulis django-rest-framework, saya memiliki bias yang jelas;) tetapi pendapat saya yang semoga cukup objektif tentang ini adalah sesuatu seperti:

TastyPie

  • Seperti dicatat Torsten, Anda tidak akan melakukan kesalahan dengan sesuatu yang ditulis oleh peeps yang sama dengan django-haystack yang mengagumkan . Dari apa yang saya lihat di milis mereka Daniel Lindsey dkk sangat membantu, dan Tastypie stabil, komprehensif dan didokumentasikan dengan baik
  • Unggul dalam memberi Anda serangkaian perilaku default yang masuk akal dan membuat membangun API dengan gaya itu sangat mudah.

Kerangka Django REST

  • Memberi Anda API penjelajahan mandiri yang dapat menelusuri HTML. (EG, lihat tutorial API .) Mampu menavigasi dan berinteraksi dengan API secara langsung di browser adalah kemenangan kegunaan yang besar.
  • Berusaha untuk tetap dekat dengan idiom Django sepanjang - dibangun di atas pandangan berbasis kelas Django, dll ... (Sedangkan TastyPie datang sebelum CBV Django ada, jadi gunakan implementasi pandangan berbasis kelas sendiri)
  • Saya ingin berpikir bahwa arsitektur yang mendasarinya dibangun dengan baik, dipisahkan dll ...

Bagaimanapun, keduanya baik. Saya mungkin akan mencirikan Tastypie sebagai memberi Anda satu set default yang masuk akal di luar kotak, dan kerangka REST sebagai sangat baik dipisahkan dan fleksibel. Jika Anda berencana menginvestasikan banyak waktu di API, saya akan merekomendasikan untuk menelusuri dokumen & basis kode masing-masing dan mencoba untuk merasakan yang lebih cocok untuk Anda.

Jelas, ada juga 'Why TastyPie?' bagian dalam README itu, dan 'REST framework 3' .

Lihat juga posting blog Daniel Greenfeld tentang Memilih kerangka kerja API untuk Django , mulai Mei 2012 (Perlu dicatat bahwa ini masih beberapa bulan sebelum rilis REST framework 2.0 yang besar).

Juga beberapa utas tentang Reddit dengan orang-orang yang menanyakan pertanyaan yang sama ini, mulai Desember 2013 dan Juli 2013 .

Tom Christie
sumber
7
Btw, Kami telah menggunakan Django-rest-framework untuk proyek besar, dan mengagumkan! Saya menguji coba tastypie selama seminggu lebih awal, dan tidak menyesal pergi bersama DRF. Dokumentasi sayangnya tidak sesuai dengan kode dan kerangka itu sendiri, tetapi selain itu, kebahagiaan murni.
Ben Roberts
Bagus sekali, terima kasih Ben. Dan ya, maksud Anda kembali. dokumentasi jelas adil. Berencana untuk mengatasinya!
Tom Christie
Tautan video "petir saya dari DjangoCon di django-rest-framework" sudah mati!
Mutant
1
@Mutant - Terima kasih, situs djangocon.eu 2011 sudah mati, tapi saya sudah ditautkan langsung ke video di blip.tv.
Tom Christie
@TomChristie Tautan ke blip.tv sudah mati sekarang! Apakah ini video yang benar?
kevins
19

Keduanya adalah pilihan yang baik.

Untuk filter, tastypie lebih kuat di luar kotak. Jika Anda memiliki tampilan yang mengekspos model, Anda dapat melakukan filter ketidaksetaraan gaya Django:

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

atau ATAU pertanyaan:

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

ini dimungkinkan dengan djangorestframework, tetapi Anda harus menulis filter khusus untuk setiap model.

Untuk traceback, saya lebih terkesan dengan django-rest-framework. Tastypie mencoba mengirim email settings.ADMINStentang pengecualian kapan DEBUG = False. Ketika DEBUG = True, pesan kesalahan default adalah serial JSON , yang lebih sulit dibaca.

Wilfred Hughes
sumber
8
Anda tidak perlu menulis filter khusus untuk ini di Django REST Framework. Anda hanya perlu menggunakan yang disediakan DjangoFilterBackendsebagaimana didokumentasikan oleh kerangka kerja REST di sini: django-rest-framework.org/api-guide/filtering#api-guide
monokrome
13

EDIT Jawaban kedaluwarsa, tastypie tidak benar-benar dipertahankan lagi. Gunakan kerangka Django REST jika Anda harus memilih kerangka kerja untuk melakukan REST.

Untuk ikhtisar tentang perbedaan aktual antara keduanya, Anda harus membaca dokumentasinya. Keduanya kurang lebih lengkap dan cukup dewasa.

Tapi saya pribadi cenderung mencicipi. Tampaknya lebih mudah untuk mengaturnya. Ini dilakukan dari orang yang sama yang membuat django-haystack yang luar biasa dan menurut django-paket lebih banyak digunakan daripada Django REST framework.

Torsten Engelbrecht
sumber
2
Dokumentasi itu bukan "gambaran umum yang baik tentang perbedaan aktual antara keduanya" sama sekali.
monokrom
Saya -1 ini karena secara signifikan sudah ketinggalan zaman dan sekarang ada kesalahan faktual: DRF sekarang lebih banyak digunakan daripada TastyPie. Yang mengatakan, penulis telah memasukkan tautan ke paket-paket Django, itu adalah jawaban yang berkualitas tinggi.
texnic
1
Berdasarkan sejarah dan masalah Github yang telah diselesaikan pada tahun 2018, tampaknya TastyPie memang masih dipertahankan.
Sushil
Tastypie didukung untuk Django 1.11, ini menghibur untuk pertimbangan proyek masa depan. django-tastypie.readthedocs.io/en/latest/…
elsadek
5

Perlu dicatat bahwa sejak pertama kali ditanya, DRF telah berubah dari kekuatan ke kekuatan.

Ini lebih aktif dari keduanya di github (baik dari segi komit, bintang, garpu, dan kontributor)

DRF memiliki dukungan OAuth 2 dan API yang dapat dijelajahi.

Jujur bagiku fitur terakhir adalah si pembunuh. Mampu mengarahkan semua pengembang front-end saya di API yang dapat dijelajahi ketika mereka tidak yakin bagaimana sesuatu bekerja dan mengatakan 'Mainkan'; cari tahu 'fantastis.

Paling tidak karena itu berarti mereka dapat memahaminya dengan persyaratan mereka sendiri dan tahu bahwa API benar-benar, benar-benar melakukan apa yang dikatakan 'dokumentasi'. Dalam dunia integrasi dengan API, fakta itu sendiri membuat DRF kerangka untuk dikalahkan.

Tom Manterfield
sumber
Saya ingin tahu apakah django-tastypie-swaggermenutup celah ini?
Victor Sergienko
2

Nah, Tastypie dan DRF keduanya adalah pilihan yang sangat baik. Anda tidak bisa salah dengan keduanya. (Saya belum pernah bekerja di Piston; dan jenisnya tidak lagi tren sekarang hari jadi tidak akan / tidak bisa mengomentarinya. Diambil untuk Granted.). Menurut pendapat saya yang sederhana: Pilihan harus dibuat atas keterampilan, pengetahuan, dan kemampuan Anda (dan tim teknologi Anda). Daripada apa yang ditawarkan TastyPie dan DRF, kecuali tentunya Anda membangun sesuatu yang sangat besar seperti Quora, Facebook atau Google.

Secara pribadi, saya akhirnya mulai bekerja pada TastyPie pada saat saya bahkan tidak tahu django dengan benar. Semuanya masuk akal pada waktu itu, hanya mengetahui REST dan HTTP dengan sangat baik tetapi dengan hampir tidak ada atau sedikit pengetahuan tentang Django. Karena satu-satunya niat saya adalah untuk membangun API RESTful dalam waktu singkat yang dapat dikonsumsi di perangkat seluler. Jadi jika Anda seperti 'Saya kebetulan waktu itu bernama django-new-bie', Jangan berpikir lebih baik untuk TastyPie.

Tetapi jika Anda memiliki pengalaman bertahun- tahun bekerja dengan Django, ketahui secara mendalam dan sangat nyaman menggunakan konsep-konsep canggih (seperti Tampilan Berbasis Kelas, Formulir, Validator Model, QuerySet, Manajer dan Instans Model dan bagaimana semua mereka berinteraksi satu sama lain), * * pilih DRF. ** DFR didasarkan pada pandangan berbasis kelas Django. DRF adalah django idiomatik. Seperti Anda menulis formulir model, validator, dll. (Yah, django idiomatik tidak ada di dekat python idiomatik. Jika Anda adalah ahli python tetapi tidak memiliki pengalaman dengan Django maka Anda mungkin mengalami kesulitan awalnya masuk ke dalam filsafat django idiomatik dan untuk itu juga penting DRF). DRF hadir dengan banyak metode sihir bawaan seperti Django. Jika Anda menyukai metode dan filosofi magis Django ** DRF ** hanya untuk Anda.

Sekarang, hanya untuk menjawab pertanyaan yang tepat:

Tastypie:

Keuntungan:

  1. Mudah untuk memulai dan memberikan fungsionalitas dasar OOB (out of the box)
  2. Sebagian besar waktu Anda tidak akan berurusan dengan konsep Django Lanjutan seperti CBV, Formulir dll
  3. Kode lebih mudah dibaca dan lebih sedikit keajaiban!
  4. Jika model Anda adalah NON-ORM, lakukan saja.

Kekurangan:

  1. Tidak sepenuhnya mengikuti Django idiomatik (pikiran baik python dan filosofi Django sangat berbeda)
  2. Mungkin agak sulit untuk menyesuaikan API setelah Anda menjadi besar
  3. Tidak Ada O-Auth

DRF:

  1. Ikuti django idiomatik. (Jika Anda tahu Django dalam ke luar, dan sangat nyaman dengan CBV, Formulir dll tanpa ragu pergi untuk itu)
  2. Menyediakan fungsionalitas REST di luar kotak menggunakan ModelViewSets. Pada saat yang sama, memberikan kontrol yang lebih besar untuk penyesuaian menggunakan CustomSerializer, APIView, GenericViews dll.
  3. Otentikasi lebih baik. Lebih mudah untuk menulis kelas izin khusus. Bekerja dengan sangat baik dan yang terpenting sangat mudah untuk membuatnya bekerja dengan perpustakaan pihak ke-3 dan OAuth. DJANGO-REST-AUTH layak disebut PERPUSTAKAAN untuk Auth / SocialAuthentication / Registrasi. ( https://github.com/Tivix/django-rest-auth )

Kekurangan:

  1. Jika Anda tidak terlalu mengenal Django, jangan lakukan ini.
  2. Sihir! Beberapa waktu sangat sulit untuk memahami sihir. Karena itu ditulis di atas CBV Django yang pada gilirannya cukup kompleks. ( https://code.djangoproject.com/ticket/6735 )
  3. Memiliki kurva belajar yang curam.

Secara pribadi apa yang akan saya gunakan dalam proyek berikutnya?

  • Sekarang, saya bukan lagi penggemar fungsi MAGIC dan Out-of-box. Karena semua itu datang dengan biaya besar. * Dengan asumsi saya memiliki semua pilihan dan kendali atas waktu dan anggaran proyek, saya akan mulai dengan sesuatu yang ringan seperti RESTLess ( https://github.com/toastdriven/restless ) (dibuat oleh pencipta TastyPie dan django-haystack ( http: //haystacksearch.org/ )). Dan untuk hal yang sama mungkin / pasti memilih kerangka kerja web yang ringan seperti Flask.

  • Tapi kenapa? - Lebih mudah dibaca, kode python idiomatik (alias pythonic) lebih mudah dibaca. Meskipun lebih banyak kode tetapi pada akhirnya memberikan fleksibilitas dan penyesuaian besar.

    • Eksplisit lebih baik daripada implisit.
    • Sederhana lebih baik daripada kompleks.
    • Kompleks lebih baik daripada rumit.
    • Flat lebih baik daripada bersarang.
    • Jarang lebih baik daripada padat.
    • Jumlah keterbacaan diperhitungkan.
    • Kasus khusus tidak cukup istimewa untuk melanggar aturan.

Bagaimana jika Anda tidak punya pilihan selain Django dan salah satu TastyPie dan DRF?

  • Sekarang, mengetahui Django cukup baik, saya akan pergi dengan ** DRF. **
  • Mengapa? - djagno idiomatik! (Aku tidak suka itu). Integrasi OAuth dan pihak ketiga yang lebih baik (Django-rest-auth adalah favorit saya).

Lalu mengapa Anda memilih DRF / TastyPie di tempat pertama?

  • Sebagian besar saya telah bekerja dengan startup dan perusahaan kecil, yang ketat dalam hal anggaran dan waktu; dan perlu memberikan sesuatu yang cepat dan bermanfaat. Django melayani tujuan ini dengan sangat baik. (Saya sama sekali tidak mengatakan bahwa Django tidak dapat diskalakan. Ada situs-situs seperti Quora, Disquss, Youtube dll berjalan di atasnya. Tapi semua itu membutuhkan waktu dan lebih dari keterampilan rata-rata)

Saya harap, ini akan membantu Anda mengambil keputusan yang lebih baik.

Referensi lain - 1. Keadaan Tastypie ( http://toastdriven.com/blog/2014/may/23/state-tastypie/ ) 2. Apa perbedaan antara django-tastypie dan djangorestframework? ( Apa perbedaan antara django-tastypie dan djangorestframework? )

Jadav Bheda
sumber
1

Setelah menggunakan keduanya, satu hal yang saya sukai (lebih disukai) tentang Django Rest Framwork adalah yang sangat konsisten dengan Django.

Penulisan serialisasi model sangat mirip dengan bentuk penulisan model. Tampilan generik bawaan sangat mirip dengan tampilan generik Django untuk HTML.

wobbily_col
sumber
1

Django-tastypie tidak lagi dipelihara oleh pembuat aslinya dan ia menciptakan kerangka kerja ringan yang baru.

Saat ini Anda harus menggunakan django-rest-framework dengan django jika Anda ingin mengekspos API Anda.

Perusahaan besar menggunakannya. django-rest-framework adalah anggota inti dari tim Django dan dia mendapatkan dana untuk mempertahankan django-rest-framework.

django-rest-framework juga memiliki banyak paket arty 3rd yang terus berkembang yang akan membantu Anda membangun API Anda lebih mudah dengan lebih sedikit kerepotan.

Beberapa bagian dari drf juga akan digabung dalam Django.

drf memberikan pola dan alat yang lebih baik daripada Django-tastypie.

Singkatnya itu dirancang dengan baik, terawat dengan baik, didanai, menyediakan aplikasi pihak ke-3 yang besar, dipercaya oleh organisasi besar, lebih mudah dan lebih sedikit boilerplate dll di atas tastypie.

auvipy
sumber