160

Django アプリの API を公開するために、なぜ一方を他方に使用するのでしょうか?

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

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

4

7 に答える 7

207

django-rest-framework の作成者として、私には明らかな偏見があります ;) しかし、これに関する私のできればかなり客観的な意見は次のようなものです。

おいしいパイ

  • Torsten が指摘したように、素晴らしいdjango-haystackと同じのぞき見によって書かれたもので、大きな間違いを犯すことはありません。彼らのメーリング リストで私が見たところによると、Daniel Lindsey などは非常に役に立ち、Tastypie は安定しており、包括的で、十分に文書化されています。
  • 賢明なデフォルト動作のセットを提供し、そのスタイルで API を非常に簡単に構築できる点で優れています。

Django REST フレームワーク

  • HTML ブラウズ可能な自己記述型 API を提供します。(例:チュートリアル APIを参照してください。) ブラウザで直接 API をナビゲートして対話できることは、ユーザビリティの大きなメリットです。
  • 全体を通して Django のイディオムに近づけようとします - Django のクラス ベースのビューなどの上に構築されています (一方、TastyPie は Django の CBV が存在する前に登場したため、独自のクラス ベースのビューの実装を使用します)。
  • 基礎となるアーキテクチャはかなりうまく構築され、分離されていると思います...

いずれにせよ、どちらも良いです。Tastypie の特徴は、すぐに使用できる実用的なデフォルトのセットを提供することであり、REST フレームワークは非常に適切に分離され、柔軟性があることです。API に多くの時間を投資することを計画している場合は、それぞれのドキュメントとコードベースを参照して、どちらがより適しているかを感じてみることをお勧めします。

明らかに、「Why TastyPie?」もあります。README のセクション、および「REST フレームワーク 3」です。

2012 年 5 月からの Django の API フレームワークの選択に関する Daniel Greenfeld のブログ投稿も参照してください(これは大きな REST フレームワーク 2.0 リリースの数か月前であることに注意してください)。

また、 2013 年 12 月から 2013 年7月にかけて、同じ質問をしている Reddit のスレッドがいくつかあります。

于 2011-09-22T16:56:22.857 に答える
19

どちらも良い選択です。

フィルターの場合、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であり、読みにくいです。

于 2013-06-04T10:28:07.637 に答える
13

EDIT時代遅れの答え、tastypie は実際にはもう維持されていません。REST を実行するフレームワークを選択する必要がある場合は、Django REST フレームワークを使用します。

両者の実際の違いに関する概要については、ドキュメントを参照してください。どちらも多かれ少なかれ完成度が高く、かなり成熟しています。

私は個人的にパイを食べる傾向があります。設定しやすくなりそうです。これは素晴らしいdjango-haystackを作成したのと同じ人々によって行われ、django-packagesによると、Django REST フレームワークよりも多く使用されています。

于 2011-09-05T04:26:27.073 に答える
2

Tastypie と DRF はどちらも優れた選択肢です。どちらでも間違いはありません。（私はこれまでピストンに取り組んだことはありません。そして、そのような種類のトレンドは最近ではなくなっているため、コメントすることはできません.当然のことです.）私の謙虚な意見では、選択はあなた (およびあなたの技術チーム) のスキル、知識、および能力に基づいて行う必要があります。TastyPie や DRF が提供するものではなく、コース外で Quora、Facebook、Google などの非常に大きなものを構築している場合を除きます。

個人的には、django のこともよく知らなかった頃から TastyPie に取り組み始めました。当時は、REST と HTTP をよく知っているだけで、django に関する知識がほとんどないか、ほとんどないため、すべてが理にかなっていました。私の唯一の意図は、モバイル デバイスで使用される RESTful API をすぐに構築することでした。だから、もしあなたが「私はたまたまその時django-new-bieと呼ばれていた」のようなら、もっとTastyPieに行くとは思わないでください.

しかし、Django を長年使用してきた経験があり、高度な概念 (クラス ベースのビュー、フォーム、モデル バリデーター、クエリセット、マネージャー、モデル インスタンス、およびそれらが相互にどのように相互作用するかなど) を完全に理解している場合は、* *DRFに行きます。**DFR は、django のクラス ベースのビューに基づいています。DRF は慣用的なジャンゴです。モデルフォームやバリデーターなどを書いているようなものです (まあ、慣用的な django は慣用的な python にはほど遠いものです。Python の専門家であるが Django の経験がない場合は、最初は慣用的な django の哲学に適合するのに苦労するかもしれません。それはDRFも重要です）。DRF には、django と同様に多くの組み込みのマジック メソッドが付属しています。Django の魔法のメソッドと哲学が好きなら、**DRF ** はまさにあなたのためのものです。

さて、正確な質問に答えるために：

テイスト:

利点:

  1. 簡単に始められ、基本的な機能を提供します OOB (箱から出して)
  2. ほとんどの場合、CBV やフォームなどの高度な Django の概念を扱うことはありません。
  3. コードがより読みやすくなり、魔法が少なくなります!
  4. モデルが非 ORM である場合は、それを選択してください。

短所:

  1. 慣用的な Django に厳密に従っているわけではありません (Python と Django の哲学はまったく異なることに注意してください)。
  2. 大きくなると、API をカスタマイズするのはおそらく少し難しい
  3. O-Auth なし

DRF:

  1. 慣用的なジャンゴに従ってください。(あなたが django を徹底的に知っていて、CBV や Forms などに非常に慣れているなら、間違いなくそれを選びましょう)
  2. ModelViewSets を使用してすぐに使える REST 機能を提供します。同時に、CustomSerializer、APIView、GenericViews などを使用してカスタマイズをより詳細に制御できます。
  3. より良い認証。カスタム権限クラスの記述が容易になります。非常にうまく動作し、重要なことに、サードパーティのライブラリと OAuth で動作させるのが非常に簡単です。DJANGO-REST-AUTH は、Auth/SocialAuthentication/Registration の LIBRARY に言及する価値があります。( https://github.com/Tivix/django-rest-auth )

短所:

  1. Django をよく知らない場合は、これを実行しないでください。
  2. 魔法！魔法を理解するのが非常に難しい時があります。これは、本質的に非常に複雑な django の 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 を使用します。**
  • なんで？- 慣用的なジャグノ！（私はそれを愛していませんが）。OAuth とサードパーティの統合が改善されました (django-rest-auth が私のお気に入りです)。

では、そもそもなぜ DRF/TastyPie を選んだのですか?

  • ほとんどの場合、私は予算と時間が限られている新興企業や中小企業と仕事をしてきました。迅速で使いやすいものを提供する必要があります。Django はこの目的を非常によく果たします。(私は、django がスケーラブルではないと言っているわけではありません。Quora、Disquss、Youtube などの Web サイトが実行されています。しかし、すべての作業には時間がかかり、平均以上のスキルが必要です)

より良い決定を下すのに役立つことを願っています。

その他の参照 - 1. Tastypie の状態 ( http://toastdriven.com/blog/2014/may/23/state-tastypie/ ) 2. django-tastypie と djangorestframework の違いは何ですか? ( django-tastypie と djangorestframework の違いは何ですか? )

于 2016-08-18T07:38:18.070 に答える
1

両方を使用して、Django Rest Framwork について私が気に入った (気に入った) ことの 1 つは、Django と非常に一貫性があることです。

モデル シリアライザーの記述は、モデル フォームの記述と非常によく似ています。組み込みの汎用ビューは、Django の HTML 用の汎用ビューに非常に似ています。

于 2016-05-12T13:52:04.747 に答える
1

Django-tastypie は元の作成者によって維持されなくなり、彼は独自の新しい軽量フレームワークを作成しました。

現在、API を公開する場合は、django で django-rest-framework を使用する必要があります。

大企業が利用しています。django-rest-framework は django チームのコアメンバーであり、django-rest-framework を維持するための資金を得ています。

django-rest-framework には、API をより簡単に手間をかけずに構築するのに役立つ、成長を続ける膨大な数の 3rd Arty パッケージもあります。

drf の一部も django 本体にマージされます。

drf は、django-tastypie よりも優れたパターンとツールを提供します。

要するに、それはうまく設計され、よく維持され、資金が提供され、大規模な組織から信頼されている巨大なサードパーティアプリを提供し、tastypie よりも簡単でボイラープレートが少ないなどです。

于 2016-12-26T13:52:43.017 に答える