django-tastypie 和 djangorestframework 有什么区别?

发布于 2024-12-03 10:39:02 字数 1431 浏览 1 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

陌若浮生 2024-12-10 10:39:02

作为 django-rest-framework 的作者,我有一个明显的偏见;)但我对此的看法是相当客观的:

TastyPie

  • 正如 Torsten 所说,你写的东西不会出错与令人敬畏的 django-haystack 一样。从我在他们的邮件列表中看到的情况来看,Daniel Lindsey 等人非常有帮助,而 Tastypie 是稳定、全面且有良好文档记录的
  • Excel,它为您提供了一组合理的默认行为,并使构建具有该风格的 API 变得非常容易。

Django REST 框架

  • 为您提供 HTML 可浏览的自描述 API。 (例如,请参阅教程 API。)能够直接在浏览器中导航并与 API 交互是可用性的巨大胜利。
  • 尝试始终接近 Django 习惯用法 - 构建在 Django 的基于类的视图之上,等等...(而 TastyPie 在 Django 的 CBV 存在之前就出现了,所以使用它自己的基于类的视图实现)
  • 我想认为底层架构构建得非常好,解耦等等......

无论如何,两者都很好。我可能会认为 Tastypie 为您提供了一组开箱即用的合理默认值,而 REST 框架则具有很好的解耦性和灵活性。如果您打算在 API 上投入大量时间,我绝对建议您浏览文档和文档。每个代码库并尝试了解哪个更适合您。

显然,自述文件中还有 'Why TastyPie?' 部分,以及 'REST框架3'

另请参阅 Daniel Greenfeld 的博客文章:为 Django 选择 API 框架,从 2012 年 5 月开始(值得注意的是,距离大型 REST 框架 2.0 发布还有几个月)。

Reddit 上还有一些帖子,有人问同样的问题,来自 2013 年 12 月2013 年 7 月

As the author of django-rest-framework, I've got an obvious bias ;) but my hopefully-fairly-objective opinion on this is something like:

TastyPie

  • As Torsten noted, you're not going to go far wrong with something written by the same peeps as the awesome django-haystack. From what I've seen on their mailing list Daniel Lindsey et al are super-helpful, and Tastypie is stable, comprehensive and well documented
  • Excels in giving you a sensible set of default behaviour and making building an API with that style incredibly easy.

Django REST framework

  • Gives you HTML browse-able self-describing APIs. (EG, see the tutorial API.) Being able to navigate and interact with the API directly in the browser is a big usability win.
  • Tries to stay close to Django idioms throughout - built on top of Django's class based views, etc... (Whereas TastyPie came along before Django's CBVs existed, so uses it's own class-based views implementation)
  • I'd like to think that the underlying architecture is pretty nicely built, decoupled etc...

In any case, both are good. I would probably characterise Tastypie as giving you a sensible set of defaults out of the box, and REST framework as being very nicely decoupled and flexible. If you're planning on investing a lot of time in the API, I'd def recommend browsing through the docs & codebase of each and trying to get a feel for which suits you more.

Obviously, there's also the 'Why TastyPie?' section in it's README, and the 'REST framework 3'.

See also Daniel Greenfeld's blog post on Choosing an API framework for Django, from May 2012 (Worth noting that this was still a few months before the big REST framework 2.0 release).

Also a couple of threads on Reddit with folks asking this same question, from Dec 2013 and July 2013.

清醇 2024-12-10 10:39:02

两者都是不错的选择。

对于过滤器,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 印象更深刻。当 DEBUG = False 时,Tastypie 尝试通过电子邮件向 settings.ADMINS 发送异常信息。当 DEBUG = True 时,默认错误消息是序列化的 JSON,较难阅读。

Both are good choices.

For filters, tastypie is more powerful out-of-the-box. If you have a view that exposes a model, you can do Django-style inequality filters:

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

or OR queries:

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

these are possible with djangorestframework, but you have to write custom filters for each model.

For tracebacks, I've been more impressed with django-rest-framework. Tastypie tries to email settings.ADMINS on exceptions when DEBUG = False. When DEBUG = True, the default error message is serialised JSON, which is harder to read.

心的憧憬 2024-12-10 10:39:02

编辑过时的答案,美味派不再真正维护。如果您必须选择一个框架来执行 REST,请使用 Django REST 框架。

要了解它们之间实际差异的概述,您应该阅读它们的文档。它们都或多或少是完整且相当成熟的。

不过我个人比较喜欢美味馅饼。设置起来似乎更容易。它是由创建 django-haystack 的同一个人完成的,这非常棒,并且根据 django-packages 它比 Django REST 框架使用更多。

EDIT Outdated answer, tastypie is not really maintained anymore. Use Django REST framework if you have to choose a framework to do REST.

For an overview about the actual differences between both of them you should read their documentation. They are both more or less complete and quite mature.

I personally tend to tastypie though. It seems to be easier to set it up. It's done from the same people which created django-haystack which is awesome and according to django-packages it is used more than Django REST framework.

回心转意 2024-12-10 10:39:02

值得注意的是,自从首次提出这个问题以来,DRF 不断发展壮大。

它是 github 上两者中更活跃的一个(无论是在提交、星星、分叉还是贡献者方面),

DRF 都有 OAuth 2 支持和可浏览的 API。

老实说,对我来说,最后一个功能是杀手锏。当我的所有前端开发人员不确定某些东西如何工作时,能够将他们指向可浏览的 API,并说“去玩吧;”找出来’太棒了。

尤其是因为这意味着他们可以按照自己的方式理解它,并知道该 API 确实、绝对、绝对按照“文档”所述进行操作。在与 API 集成的领域中,仅这一事实就使 DRF 成为了值得击败的框架。

It's worth noting that since this was first asked DRF has gone from strength to strength.

It's the more active of the two on github (both in terms of commits, stars, forks and contributors)

DRF has OAuth 2 support and the browsable API.

Honestly for me that last feature is the killer. Being able to point all my front-end devs at the browsable API when they aren't sure how something works and say 'Go play; find out' is fantastic.

Not least because it means they get to understand it on their own terms and know that the API really, definitely, absolutely does what the 'documentation' says it does. In the world of integrating with APIs, that fact alone makes DRF the framework to beat.

酷遇一生 2024-12-10 10:39:02

那么,Tastypie 和 DRF 都是不错的选择。使用它们中的任何一个都不会出错。 (我从来没有在活塞上工作过;现在它已经不再流行了,所以不会/不能评论它。理所当然。)。
以我的拙见:应该根据您(和您的技术团队)的技能、知识和能力做出选择。而不是根据 TastyPie 和 DRF 提供的功能进行选择,除非您正在构建像这样非常大的东西Quora、Facebook 或 Google。

就我个人而言,当我什至不太了解 django 时,我最终开始了 TastyPie 的工作。当时这一切都是有道理的,只了解 REST 和 HTTP,但对 django 几乎一无所知或知之甚少。因为我唯一的目的是立即构建 RESTful API,以便在移动设备中使用。因此,如果您就像“我当时碰巧被称为 django-new-bie”,不要考虑更多,选择 TastyPie。

但如果您有很多 > 拥有使用 Django 的经验,对它了如指掌,并且非常熟悉使用高级概念(例如基于类的视图、表单、模型验证器、查询集、管理器和模型实例以及它们如何相互交互),**选择 DRF。 **DFR 基于 django 的基于类的视图。
DRF 是惯用的 django。这就像你正在编写模型表单、验证器等(好吧,惯用的 django 与惯用的 python 相差甚远。如果你是 python 专家,但没有 Django 经验,那么你可能很难一开始就适应惯用的 django 哲学,并且对于DRF 也很重要)。
DRF 带有许多内置的魔法方法,就像 django 一样。如果您喜欢 django 的神奇方法和哲学 **DRF ** 正适合您。

现在,只是回答确切的问题:

Tastypie:

优点:

  1. 易于上手并提供基本功能 OOB(开箱即用)
  2. 大多数时候您不会'不必处理 CBV、表单等高级 Django 概念,
  3. 代码更可读,魔法更少!
  4. 如果你的模型是非 ORM 的,那就去做吧。

缺点

  1. 不严格遵循惯用的 Django(请注意 python 和 django 的哲学是完全不同的)
  2. 一旦你变得强大,定制 API 可能会有点困难
  3. 没有 O-Auth

DRF:

  1. 遵循惯用的 django。 (如果您对 django 了如指掌,并且对 CBV、Forms 等非常熟悉,毫无疑问就去吧)
  2. 使用 ModelViewSets 提供开箱即用的 REST 功能。同时,使用 CustomSerializer、APIView、GenericViews 等提供更好的自定义控制
  3. 。更好的身份验证。更容易编写自定义权限类。工作得很好,重要的是很容易使其与 3rd 方库和 OAuth 一起工作。 DJANGO-REST-AUTH 是值得一提的用于身份验证/社交身份验证/注册的库。 (https://github.com/Tivix/django-rest-auth)

< em>缺点:

  1. 如果您不太了解 Django,请不要这样做。
  2. 魔法!有时很难理解魔法。因为它是在 django 的 CBV 之上编写的,而 CBV 本质上又相当复杂。 (https://code.djangoproject.com/ticket/6735)
  3. 学习曲线陡峭。

就我个人而言,我会在下一个项目中使用什么?

  • 现在,我不再喜欢 MAGIC 和开箱即用功能。因为所有这些都需要付出巨大的代价。 * 假设我对项目时间和预算有所有选择和控制,我会从轻量级的东西开始,比如 RESTLess (https: //github.com/toastdriven/restless)(由 TastyPie 和 django-haystack 的创建者创建(http://haystacksearch.org/))。对于同样的问题,可能/肯定会选择像 Flask 这样的轻量级 Web 框架。

  • 但是为什么呢? - 更可读、更简单、更易于管理的惯用Python(又名Pythonic)代码。虽然代码较多,但最终提供了极大的灵活性和定制性。

    • 显式优于隐式。
    • 简单胜于复杂。
    • 复杂总比复杂好。
    • 扁平比嵌套更好。
    • 稀疏优于密集。
    • 可读性很重要。
    • 特殊情况还不足以违反规则。

如果除了 Django 以及 TastyPie 和 DRF 之一之外别无选择怎么办?

  • 现在,我对 Django 相当了解,我将选择 **DRF。 **
  • 为什么? - 惯用的djagno! (虽然我不喜欢它)。更好的 OAuth 和第 3 方集成(django-rest-auth 是我的最爱)。

那为什么你首先选择了 DRF/TastyPie?

  • 我主要与初创公司和小公司合作,这些公司的预算和时间都很紧张;并需要提供快速且可用的东西。 Django 很好地实现了这个目的。 (我并不是说 django 不可扩展。Quora、Disquss、Youtube 等网站都可以在上面运行。但所有这些都需要时间和比平均技能更高的技能)

我希望,它会帮助您做出更好的决定。

其他参考资料 -
1. Tastypie 的状态 (http://toastdriven.com/blog/ 2014年5月23日state-tastypie/)
2. django-tastypie 和 djangorestframework 有什么区别? ( django-tastypie 和 djangorestframework?)

Well, Tastypie and DRF both are excellent choices. You simply can’t go wrong with either of them. (I haven’t worked on Piston ever; and its kind of not trending anymore now a days so won’t / can’t comment on it. Taken for Granted.).
In my humble opinion: Choice should be made on yours (and your tech team’s) skills, knowledge and capabilities. Rather than on what TastyPie and DRF offers, unless off-course you are building something really big like Quora, Facebook or Google.

Personally, I ended up starting working first on TastyPie at a time when I didn’t even know django properly. It all made sense at that time, only knowing REST and HTTP very well but with almost no or little knowledge about django. Because my only intention was to build RESTful APIs in no time which were to be consumed in mobile devices. So if you are just like ‘I happen to be at that time called django-new-bie’, Don’t think more go for TastyPie.

But if you have many years of experience working with Django, knows it inside out and very comfortable using advanced concepts (like Class Based Views, Forms, Model Validator, QuerySet, Manager and Model Instances and how all they interact with one another), **go for DRF. **DFR is bases on django’s class based views.
DRF is idiomatic django. Its like you are writing model forms, validators etc. (Well, idiomatic django is no where near to idiomatic python. If you are python expert but have no experience with Django then you might be having hard time initially fit into idiomatic django philosophy and for that matter DRF as well).
DRF comes with lots of inbuilt magic methods just like django. If you love the django magical methods and philosophy **DRF **is just for you.

Now, just to answer the exact question:

Tastypie:

Advantages:

  1. Easy to get started with and provide basic functionalities OOB (out of the box)
  2. Most of the time you won’t be dealing with Advanced Django concepts like CBVs, Forms etc
  3. More readable code and less of magic!
  4. If your models are NON-ORM, go for it.

Disadvantages:

  1. Doesn’t strictly follow idiomatic Django (mind well python and django’s philosophies are quite different)
  2. Probably bit tough to customize APIs once you go big
  3. No O-Auth

DRF:

  1. Follow idiomatic django. (If you know django inside out, and very comfortable with CBV, Forms etc without any doubt go for it)
  2. Provides out of the box REST functionality using ModelViewSets. At the same time, provides greater control for customization using CustomSerializer, APIView, GenericViews etc.
  3. Better authentication. Easier to write custom permission classes. Work very well and importantly very easy to make it work with 3rd party libraries and OAuth. DJANGO-REST-AUTH is worth mentioning LIBRARY for Auth/SocialAuthentication/Registration. (https://github.com/Tivix/django-rest-auth)

Disadvantages:

  1. If you don’t know Django very well, don’t go for this.
  2. Magic! Some time very hard to understand magic. Because its been written on top of django’s CBV which are in turn quite complex in nature. (https://code.djangoproject.com/ticket/6735)
  3. Has steep learning curve.

Personally what would I use in my next project?

  • Now, I am no more a fan of MAGIC and Out-of-box functionalities. Because all they come at a *great cost. * Assuming I have all choices and control over project time and budget, I would start with something light weight like RESTLess (https://github.com/toastdriven/restless) (created by the creator of TastyPie and django-haystack (http://haystacksearch.org/)). And for the same matter probably/definately choose the lightweight web framework like Flask.

  • But why? - More readable, simple and manageable idiomatic python (aka pythonic) code. Though more code but eventually provide great flexibility and customization.

    • Explicit is better than implicit.
    • Simple is better than complex.
    • Complex is better than complicated.
    • Flat is better than nested.
    • Sparse is better than dense.
    • Readability counts.
    • Special cases aren't special enough to break the rules.

What if you have only no choice but Django and one of TastyPie and DRF?

  • Now, knowing the Django reasonably well, I will go with **DRF. **
  • Why? - idiomatic djagno! (I don’t love it though). Better OAuth and 3rd party integration (django-rest-auth is my favorite).

Then why you chose the DRF/TastyPie at first place?

  • Mostly I have worked with startups and small firms, which are tight on budget and time; and need to deliver something quick and usable. Django serve this purpose very well. (I am not at all saying that django is not scalable. There are websites like Quora, Disquss, Youtube etc run on it. But all it require time and more then average skills)

I hope, it will help you to take better decision.

Other references -
1. The State of Tastypie (http://toastdriven.com/blog/2014/may/23/state-tastypie/)
2. What are the differences between django-tastypie and djangorestframework? (What are the differences between django-tastypie and djangorestframework?)

听风吹 2024-12-10 10:39:02

使用过两者后,我喜欢(首选)Django Rest Framwork 的一件事是它与 Django 非常一致。

编写模型序列化器与编写模型表单非常相似。内置的通用视图与 Django 的 HTML 通用视图非常相似。

Having used both, one thing that I liked (preferred) about Django Rest Framwork is that is is very consistent with Django.

Writing model serializers is very similar to writing model forms. The built in Generic Views are very similar to Django's generic views for HTML.

糖果控 2024-12-10 10:39:02

Django-tastypie 不再由它的原始创建者维护,他创建了自己的新的轻量级框架。

目前,如果您愿意公开您的 API,您应该将 django-rest-framework 与 django 一起使用。

大公司正在使用它。 django-rest-framework 是 django 团队的核心成员,他获得资金来维护 django-rest-framework。

django-rest-framework 也有大量不断增长的第三个 arty 包,这将帮助您更轻松地构建 API,减少麻烦。

drf 的某些部分也将合并到 django 中。

drf 提供了比 django-tastypie 更多更好的模式和工具。

简而言之,它设计精良、维护良好、资金充足、提供庞大的第 3 方应用程序、受到大型组织的信任、比 tastypie 更简单、更少的样板文件等。

Django-tastypie is no longer maintained by it's original creator and he created a new light weight framework of his own.

At present you should use django-rest-framework with django if you are willing to expose your API.

Large corporations are using it. django-rest-framework is a core member of django team and he get funding to maintain django-rest-framework.

django-rest-framework also have huge number of ever growing 3rd arty packages too which will help you build your API's more easily with less hassles.

Some part of drf will also be merged in django proper.

drf provide more better patterns and tools then django-tastypie.

In short it's well designed, well maintained, funded, provide huge 3rd party apps, trusted by large organisations, easier and less boilerplate etc over tastypie.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文