Які відмінності між django-tastypie та djangorestframework? [зачинено]

Чому б ви використовували один над іншим для відкриття API для додатка Django?

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

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

Як автор рамки django-rest, я маю очевидну упередженість;), але моя, сподіваюся, досить об’єктивна думка щодо цього є чимось на кшталт:

TastyPie

• Як зауважив Торстен, ви не збираєтеся піти неправильно з тим, що написано тими ж підглядами, як і дивовижна джанго-копиця сіна . З того, що я бачив у їхньому списку розсилки, Даніель Ліндсі та ін є надзвичайно корисними, а Tastypie стабільний, всебічний та добре задокументований
• Видатно надає вам розумний набір поведінки за замовчуванням та робить побудову API з цим стилем неймовірно простою.

Рамка Django REST

• Надає вам API для самоопису HTML, здатний переглядати HTML. (EG, див. API навчального посібника .) Можливість навігації та взаємодії з API безпосередньо в браузері - це велика перемога у використанні.
• Намагається залишатися поруч із ідіомами Джанго на всьому протязі - будується на базі класу, що базується на Django, тощо ... (В той час, як TastyPie з'явився ще до існування ЦБД Django, тому використовує власну реалізацію класових поглядів)
• Я хотів би подумати, що основна архітектура досить гарно побудована, розв'язана тощо.

У будь-якому випадку і те, і інше добре. Я, мабуть, охарактеризував би Tastypie як надання розумного набору за замовчуванням поза коробкою, а REST фреймворк як дуже красиво відокремлений та гнучкий. Якщо ви плануєте інвестувати багато часу в API, я б рекомендував переглядати документи та кодову базу кожного з них і намагатися зрозуміти, що вам більше підходить.

Очевидно, є також "Чому TastyPie?" розділ у ньому README та 'REST Framework 3' .

Дивіться також повідомлення в блозі Даніеля Грінфельда про вибір рамки API для Django з травня 2012 року (Варто зазначити, що до великого випуску REST Framework 2.0 було ще кілька місяців).

Також пару тем на Reddit з людьми, які задають це те саме питання, з грудня 2013 року та липня 2013 року .

Обидва - хороший вибір.

Що стосується фільтрів, tastypie є більш потужним поза коробкою. Якщо у вас є вид, що демонструє модель, ви можете зробити фільтри нерівності у стилі Джанго:

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

або АБО запити:

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

це можливо за допомогою djangorestframework, але вам потрібно написати спеціальні фільтри для кожної моделі.

Щодо відслідковування, мене більше вразила система django-rest-frame. Коли Tastypie намагається надіслати електронну пошту settings.ADMINSпро винятки, коли DEBUG = False. Коли DEBUG = True, повідомлення про помилку за замовчуванням серіалізується JSON , що важче читати.

EDIT Застаріла відповідь, tastypie насправді вже не підтримується. Використовуйте рамку Django REST, якщо вам потрібно вибрати рамку для REST.

Для огляду фактичних відмінностей обох ви повинні прочитати їх документацію. Вони обидва більш-менш повноцінні і досить зрілі.

Я особисто схильний до tastypie. Здається, це простіше налаштувати. Це зроблено від тих самих людей, які створили джанго-копицю сіна, яка є приголомшливою, і згідно з пакетами django використовується більше, ніж рамка Django REST.

Варто зазначити, що оскільки це було вперше, ДРФ перейшов від сили до сили.

Це активніше з двох на github (як з точки зору комітів, зірок, вилок та дописувачів)

DRF має підтримку OAuth 2 та API для перегляду.

Чесно кажучи, що остання риса - це вбивця. Будучи в змозі вказати всі мої розгорнуті диски на API, який можна переглянути, коли вони не впевнені, як щось працює, і сказати: «Іди грай; дізнатися 'це фантастично.

Не в останню чергу тому, що це означає, що вони розуміють це на власних умовах і знають, що API справді, безумовно, абсолютно робить те, що «документація» говорить, що це робить. У світі інтеграції з API, саме цей факт робить DRF основою для перемоги.

Ну, і Tastypie, і DRF - це відмінний вибір. Ви просто не можете помилитися ні з одним із них. (Я не працював над «Порстон» ніколи; і його вид уже не трендає вже кілька днів, тому не можу / не можу прокоментувати це. Зроблено для Granted.) На мою скромну думку: вибір повинен бути зроблений на основі ваших навичок, знань та можливостей вашої технічної команди. Замість того, щоб запропонувати TastyPie та DRF, якщо ви, поза межами, не будуєте щось дійсно велике, як Quora, Facebook чи Google.

Особисто я вперше почав працювати над TastyPie в той момент, коли навіть не знав джанго належним чином. В цей час все було сенс, тільки добре знаючи REST та HTTP, але майже не знаючи або мало знань про джанго. Тому що мій єдиний намір полягав у тому, щоб за короткий час створити API RESTful, які мали використовуватись у мобільних пристроях. Тож якщо ви просто схожі на те, що "мене, на той час, називають django-new-bie", не думайте більше йти на TastyPie.

Але якщо у вас є багаторічний досвід роботи з Django, знає це зсередини і дуже зручно, використовуючи передові концепції (наприклад, перегляди на основі класів, форми, валідатор моделей, QuerySet, менеджер та моделі моделей та те, як вони взаємодіють між собою), * * ідіть на DRF. ** DFR - це основи класичного вигляду джанго. ДРФ - ідіоматичне джанго. Начебто ти пишеш типові форми, валідатори тощо (ну, ідіоматичне джанго - це не те, що наближено до ідіоматичного пітона. Якщо ти експерт з пітонів, але не маєш досвіду роботи з Джанго, то, можливо, спочатку ти будеш важко вписуватися у філософію ідіоматичного джанго і що також має значення DRF). ДРФ поставляється з безліччю вбудованих магічних методів, як і джанго. Якщо ви любите магічні методи джанго та філософію ** DRF ** - саме для вас.

Тепер просто відповісти на точне запитання:

Tastypie:

Переваги:

1. Легко розпочати роботу та забезпечити основні функціональні можливості OOB (поза коробкою)
2. Більшу частину часу ви не будете мати справу з розширеними концепціями Джанго, такими як CBV, Forms тощо
3. Більш читабельний код і менше магії!
4. Якщо ваші моделі не-ORM, перейдіть на це.

Недоліки:

1. Не суворо дотримується ідіоматичного Джанго (розум добре філософії пітона і джанго зовсім інші)
2. Напевно, трохи важко налаштувати API, коли ви зробите великий
3. Ні O-Auth

DRF:

1. Дотримуйтесь ідіоматичного джанго. (Якщо ви знаєте джанго зсередини, і вам дуже зручно працювати з CBV, Forms тощо, без сумнівів, продовжуйте це робити)
2. Забезпечує функціональність REST за допомогою ModelViewSets. У той же час, забезпечує більший контроль за налаштуванням за допомогою CustomSerializer, APIView, GenericViews тощо
3. Краща аутентифікація. Простіше писати спеціальні класи дозволів. Працюйте дуже добре і, що важливо, дуже просто, щоб зробити роботу з сторонніми бібліотеками та OAuth. DJANGO-REST-AUTH варто згадати БІБЛІОТЕК для авторизації / соціальної перевірки / реєстрації. ( https://github.com/Tivix/django-rest-auth )

Недоліки:

1. Якщо ви не дуже добре знаєте Джанго, не робіть цього.
2. Магія! Деякий час дуже важко зрозуміти магію. Тому що його написано поверх CBV джанго, які, у свою чергу, є досить складними за своєю суттю. ( https://code.djangoproject.com/ticket/6735 )
3. Має круту криву навчання.

Що б я особисто використав у своєму наступному проекті?

• Тепер я більше не шанувальник функцій MAGIC та out-of-box. Тому що всі вони приходять за * велику ціну. * Якщо припустити, що у мене є всі варіанти та контроль за часом та бюджетом проекту, я б почав із чогось легкої ваги, як RESTLess ( https://github.com/toastdriven/restless ) (створений творцем TastyPie та django-копиці сіна ( http: //haystacksearch.org/ )). І для того ж питання, ймовірно, / напевно виберіть легку веб-рамку, як Flask.

• Але чому? - Більш читаний, простий та керований ідіоматичний пітон (також пітонічний) код. Хоча більше коду, але зрештою забезпечують велику гнучкість та налаштування.

  • Явне краще, ніж неявне.
  • Простий - краще, ніж складний.
  • Комплекс краще, ніж складний.
  • Квартира краще, ніж вкладена.
  • Розріджений краще, ніж щільний.
  • Читання рахується.
  • Особливі випадки недостатньо спеціальні для порушення правил.

Що робити, якщо у вас немає лише іншого вибору, окрім Джанго та одного з TastyPie та DRF?

• Тепер, знаючи Джанго досить добре, я піду з ** ДРФ. **
• Чому? - ідіоматичне джаньо! (Я не люблю це, хоча). Краща інтеграція OAuth і сторона (django-rest-auth - мій улюблений).

Тоді чому ви обрали спочатку DRF / TastyPie?

• Здебільшого я працював зі стартапами та невеликими фірмами, які обмежують бюджет та час; і потрібно доставити щось швидке та корисне. Джанго дуже добре служить цій цілі. (Я зовсім не кажу, що джанго не є масштабованим. На ньому працюють веб-сайти, такі як Quora, Disquss, Youtube тощо. Але для цього потрібен час і більше, ніж середні навички)

Сподіваюсь, це допоможе вам прийняти краще рішення.

Інші посилання - 1. Держава Tastypie ( http://toastdriven.com/blog/2014/may/23/state-tastypie/ ) 2. Які відмінності між django-tastypie та djangorestframework? ( Які відмінності між django-tastypie та djangorestframework? )

Використовуючи і те, і інше, що мені сподобалось (вважалося за краще) про Django Rest Framwork, це те, що дуже відповідає Django.

Написання модельних серіалізаторів дуже схоже на написання модельних форм. Вбудовані в Generic Views дуже схожі на загальні погляди Django для HTML.

Її оригінальний творець вже не підтримує Джанго-смастіпі, і він створив нові власні рамки для легкої ваги.

В даний час ви повинні використовувати django-rest-frame з django, якщо ви готові викрити свій API.

Великі корпорації використовують це. django-rest-Framework є основним членом команди django, і він отримує фінансування для підтримки системи django-rest.

django-rest-Framework також має величезну кількість постійно зростаючих 3-х арт-пакетів, що допоможе вам легше створити API, з меншими клопотами.

Деяка частина drf також буде об'єднана у власне джанго.

drf надає кращі візерунки та інструменти, ніж django-tastypie.

Коротше кажучи, це добре розроблений, доглянутий, профінансований, надає величезні додатки сторонніх організацій, яким довіряють великі організації, простіший та менший розмір котлів тощо за допомогою tastypie.