Каковы различия между django-tastypie и djangorestframework?

Оба являются хорошим выбором.

Для фильтров tastypie является более мощным готовым к использованию. Если у вас есть представление, которое предоставляет модель, вы можете использовать фильтры неравенства в стиле Django:

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

или OR:

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

это возможно с помощью djangorestframework, но вы должны писать собственные фильтры для каждой модели.

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

EDIT Устаревший ответ, tastypie больше не поддерживается. Используйте среду Django REST, если вам нужно выбрать структуру для выполнения REST.

Для обзора фактических различий между ними вы должны прочитать их документацию. Они более или менее полны и достаточно зрелы.

Я лично склонен к тастипии. Кажется, что проще настроить его. Это сделано от тех же людей, которые создали django-haystack, который является удивительным и согласно django-packages используется больше, чем структура Django REST.

Стоит отметить, что, поскольку это было впервые задано, DRF перешла от силы к силе.

Это более активное из двух на github (как с точки зрения коммитов, звезд, вилок и участников)

У DRF есть поддержка OAuth 2 и API-интерфейс, доступный для просмотра.

Честно говоря, для меня эта последняя функция - убийца. Возможность указывать всем моим сторонним разработчикам в API-интерфейсе, когда они не уверены, как что-то работает, и сказать "Go play; узнать" - это фантастика.

Не в последнюю очередь потому, что это означает, что они понимают это на своих условиях и знают, что API действительно определенно делает то, что говорит "документация". В мире интеграции с API-интерфейсами этот факт сам по себе делает DRF фреймворком.

Django-tastypie больше не поддерживается его оригинальным создателем, и он создал новую легковую структуру своего собственного.

В настоящее время вы должны использовать django-rest-framework с django, если вы готовы предоставить свой API.

Крупные корпорации используют его. django-rest-framework является основным членом команды django, и он получает финансирование для поддержания django-rest-framework.

django-rest-framework также имеет огромное количество постоянно растущих 3-х арт-пакетов, которые помогут вам с легкостью построить свой API с меньшими проблемами.

Некоторая часть drf также будет объединена в собственно django.

drf предоставляют более качественные шаблоны и инструменты, чем django-tastypie.

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

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

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

Но если у вас есть много лет опыта работы с Django, он знает его наизнанку и очень удобен с использованием передовых концепций (таких как представления на основе классов, формы, модельный валидатор, QuerySet, диспетчер и экземпляры моделей и как все они взаимодействуют друг с другом), ** перейти на DRF. ** DFR основывается на представлениях класса djangos. DRF - это идиоматическое джанго. Это похоже на то, что вы пишете модельные формы, валидаторы и т.д. (Ну, идиоматический django - это не где-то рядом с идиоматическим питоном. Если вы эксперт по python, но не имеете опыта работы с Django, то вам может быть трудно вначале вписываться в идиоматическую философию django и для это вещество DRF также). DRF поставляется с множеством встроенных магических методов, таких как django. Если вы любите магические методы и философию django ** DRF ** для вас.

Теперь, чтобы ответить на точный вопрос:

Tastypie:

Преимущества:

• Легко начать работу с базовыми функциями OOB (из коробки)
• В большинстве случаев вы не будете иметь дело с расширенными концепциями Django, такими как CBV, Forms и т.д.
• Более читаемый код и меньше магии!
• Если ваши модели не имеют ORM, пойдите для этого.

Недостатки:

• Не следует строго следовать идиоматическому Django (ум хорошо питон и философия djangos совершенно разные).
• Возможно, вам сложно настроить API, когда вы идете большими
• Нет O-Auth

DRF:

• Следуйте идиоматическому джанго. (Если вы знаете django наизнанку и очень комфортно с CBV, Forms и т.д., Не сомневайтесь в этом).
• Предоставляет возможность использования функции REST с помощью ModelViewSets. В то же время, обеспечивает более широкий контроль для настройки с помощью CustomSerializer, APIView, GenericViews и т.д.
• Улучшена аутентификация. Легче писать пользовательские классы разрешений. Работайте очень хорошо и очень легко, чтобы он работал с сторонними библиотеками и OAuth. DJANGO-REST-AUTH стоит упомянуть БИБЛИОТЕКУ для Auth/SocialAuthentication/Registration. (https://github.com/Tivix/django-rest-auth)

Недостатки:

• Если вы не знаете Django очень хорошо, не идите на это.
• Магия! Некоторое время очень трудно понять магию. Потому что он был написан поверх djangos CBV, которые в свою очередь довольно сложны по своей природе. (https://code.djangoproject.com/ticket/6735)
• имеет крутую кривую обучения.

Лично, что бы я использовал в своем следующем проекте?

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

• Но почему? - Более читаемый, простой и управляемый идиоматический код python (aka pythonic). Хотя больше кода, но в конечном итоге обеспечивают большую гибкость и настройку.

  • Явный лучше, чем неявный.
  • Простой лучше, чем сложный.
  • Комплекс лучше, чем сложный.
  • Плоский лучше, чем вложенный.
  • Рельеф лучше плотного.
  • Показатели удобочитаемости.
  • Специальные случаи не являются достаточно сложными, чтобы нарушать правила.

Что делать, если у вас нет выбора, кроме Django и одного из TastyPie и DRF?

• Теперь, зная Django достаточно хорошо, я пойду с ** DRF. **
• Почему? - идиоматическое дягно! (Я не люблю его, хотя). Лучшая OAuth и сторонняя интеграция (django-rest-auth - мой любимый).

Тогда почему вы выбрали DRF/TastyPie на первом месте?

• В основном я работал с стартапами и небольшими фирмами, которые напряжены по бюджету и времени; и нужно доставить что-то быстрое и удобное. Джанго очень хорошо справляется с этой задачей. (Я вовсе не говорю, что django не масштабируется. На нем работают такие сайты, как 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.

Написание модельных сериализаторов очень похоже на создание форм модели. Встроенные общие представления очень похожи на общие представления Django для HTML.