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

Зачем вам использовать один над другим для предоставления API для вашего приложения Django?

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

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

Как автор django-rest-framework, у меня очевидный уклон;) но мое, надеюсь, довольно объективное мнение по этому поводу выглядит примерно так:

TastyPie

• Как заметил Торстен, вы не ошибетесь с тем, что написано теми же писками, что и потрясающий джанго-стог сена . Из того, что я видел в их списке рассылки, Дэниэл Линдси и др. Очень полезны, а Tastypie стабильна, всеобъемлюща и хорошо документирована.
• Превосходно дает вам разумный набор поведения по умолчанию и делает создание API с таким стилем невероятно простым.

Django REST framework

• Дает вам API с самоописанием для просмотра в HTML. (Например, см. Учебник API .) Возможность навигации и взаимодействия с API непосредственно в браузере - большой выигрыш в удобстве использования.
• Пытается всегда быть рядом с идиомами Django - построенными на основе представлений Django, основанных на классах, и т. Д. (Принимая во внимание, что TastyPie появился еще до появления CBV Django, поэтому использует собственную реализацию представлений на основе классов)
• Я хотел бы думать, что базовая архитектура довольно хорошо построена, отделена и т.д ...

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

Очевидно, есть также «Почему TastyPie?» раздел в этом README, и 'REST framework 3' .

См. Также сообщение в блоге Дэниела Гринфельда « Выбор структуры API для Django» с мая 2012 года (стоит отметить, что до выхода большой версии REST Framework 2.0 оставалось еще несколько месяцев).

Также пара тем на Reddit с людьми, задающими этот же вопрос, с декабря 2013 года и июля 2013 года .

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

Для фильтров вкусный пирог является более мощным из коробки. Если у вас есть представление, представляющее модель, вы можете использовать фильтры неравенства в стиле 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 , который труднее читать.

РЕДАКТИРОВАТЬ Устаревший ответ, вкусный пирог больше не поддерживается. Используйте Django REST framework, если вам нужно выбрать каркас для REST.

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

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

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

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

DRF имеет поддержку OAuth 2 и API с возможностью просмотра.

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

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

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

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

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

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

Tastypie:

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

1. Легко начать и обеспечить основные функциональные возможности OOB (из коробки)
2. Большую часть времени вы не будете иметь дело с продвинутыми концепциями Django, такими как CBV, Forms и т. Д.
3. Более читаемый код и меньше волшебства!
4. Если ваши модели не-ОРМ, пойти на это.

Недостатки:

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

ФПИ:

1. Следуй идиоматическому Джанго. (Если вы знаете django наизнанку, и вам очень удобно с 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 и готовых функциональных возможностей. Потому что все они приходят по * большой цене. * Предполагая, что у меня есть все варианты и контроль над временем и бюджетом проекта, я бы начал с чего-то более легкого, например RESTLess ( https://github.com/toastdriven/restless ) (созданного создателем TastyPie и django-haystack ( http: //haystacksearch.org/ )). И по той же причине, вероятно, определенно выберите легкий веб-фреймворк, такой как Flask.

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

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

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

• Теперь, зная Джанго достаточно хорошо, я пойду с ** 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.

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

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

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

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

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

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

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