質問

DjangoアプリにAPIを公開するために、なぜ1つを使用するのですか?

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

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

役に立ちましたか?

解決

django-rest-frameworkの著者として、私は明らかな偏見を持っています;)しかし、これについての私の断りの客観的な意見は次のようなものです。

テイスティピー

  • Torstenが指摘したように、あなたは素晴らしいものと同じように書かれたものでそれほど間違っていないでしょう django-haystack. 。私が彼らのメーリングリストで見たものから、ダニエル・リンジーらは非常に熟練しており、テイスティピーは安定していて、包括的で十分に文書化されています
  • デフォルトの動作の賢明なセットを提供し、そのスタイルでAPIを構築することに非常に簡単になります。

Django RESTフレームワーク

  • HTML Browse-able自己記述APIを提供します。 (例を参照してください チュートリアルAPI。)ブラウザでAPIを直接ナビゲートしてやり取りできることは、ユーザビリティの大きな勝利です。
  • Djangoのクラスベースのビューなどの上に構築されたDjango Idiomsの近くにとどまることを試みています...(DjangoのCBVが存在する前にThastypieが登場するので、独自のクラスベースのビューの実装を使用します)
  • 基礎となるアーキテクチャはかなりうまく構築されており、デカップされたものなどだと思います...

いずれにせよ、どちらも良いです。私はおそらく、Tastypieを、箱から出して賢明なデフォルトのセットを提供し、RESTフレームワークが非常にうまく分離され、柔軟であると特徴づけると思います。 APIに多くの時間を投資することを計画している場合は、それぞれのドキュメントとコードベースを閲覧して、自分に合った感覚を得ようとすることをお勧めします。

明らかに、それもあります 「なぜテイスティピー?」 readmeのセクション、および 「RESTフレームワーク3」.

Daniel Greenfeldのブログ投稿も参照してください DjangoのAPIフレームワークの選択, 、2012年5月から(これは、Big Rest Framework 2.0リリースの数ヶ月前にまだあることに注意してください)。

また、Redditのいくつかのスレッドが、この同じ質問をしている人々と一緒に 2013年12月2013年7月.

他のヒント

どちらも良い選択です。

フィルターの場合、TastyPieはすぐに使用できるようになります。モデルを公開するビューがある場合は、Djangoスタイルの不平等フィルターを実行できます。

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

またはまたはクエリ:

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

これらはDjangorestFrameworkで可能ですが、各モデルにカスタムフィルターを記述する必要があります。

Tracebacksについては、Django-Rest-Frameworkにもっと感銘を受けました。 StastyPieは電子メールを試みます settings.ADMINS 例外として DEBUG = False. 。いつ DEBUG = True, デフォルトのエラーメッセージは、シリアル化されたJSONです, 、読みにくいです。

編集 時代遅れの答え、Tastypieはもう維持されていません。休憩するためにフレームワークを選択する必要がある場合は、Django RESTフレームワークを使用してください。

両方の実際の違いについての概要については、ドキュメントを読む必要があります。どちらも多かれ少なかれ完全であり、非常に成熟しています。

私は個人的にはテイスピーする傾向があります。セットアップする方が簡単なようです。それは作成したのと同じ人々から行われています django-haystack それは素晴らしいです Django-Packages Django Rest Framework以上に使用されています。

これが最初に尋ねられたので、DRFが強さから強さへと尋ねられたことは注目に値します。

Githubの2つの方がアクティブです(コミット、スター、フォーク、貢献者の両方)

DRFにはOAuth 2のサポートと閲覧可能なAPIがあります。

正直なところ、その最後の機能はキラーです。何かがどのように機能するかわからないときに、すべてのフロントエンド開発者を眉間APIに向けることができ、「遊びに行く」と言うことができます。調べる」は素晴らしいです。

特に、それは彼らが自分の条件でそれを理解し、APIが本当に、間違いなく、「ドキュメント」が言うことを絶対に行うことを知っていることを意味するからです。 APIとの統合の世界では、その事実だけでDRFが倒すフレームワークになります。

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

モデルのシリアルザーの書き込みは、モデルフォームの作成に非常に似ています。組み込みの一般的なビューは、HTMLに対するDjangoの一般的なビューに非常に似ています。

まあ、ThastypieとDRFはどちらも優れた選択です。あなたは単に できません どちらかを間違えます。 (私はピストンに取り組んでいません。そして、そのようなものはもう一日を流していないので、それについてコメントしません /できません。当たり前のことと考えられています。)私の愚見で: 自分(および技術チーム)のスキル、知識、能力を選択する必要があります。 TastypieとDRFが提供するものではなく、コース外でない限り、Quora、Facebook、Googleのような本当に大きなものを構築しています。

個人的には、Djangoを適切に知らなかったときに、最初にTastypieで作業を開始することになりました。当時はすべて理にかなっており、休息とhttpだけをよく知っているだけですが、Djangoについての知識はほとんどありませんでした。私の唯一の意図は、モバイルデバイスで消費されるのにすぐに安らかなAPIを構築することだったからです。だからあなたが「私がたまたまDjango-new-bieと呼ばれる」と同じなら、 Thastypieにこれ以上行くとは思わないでください。

しかし、あなたがたくさん持っているなら Djangoとの仕事の経験は、それを裏返しに知っており、高度な概念(クラスベースのビュー、フォーム、モデルバリデーター、クエリセット、マネージャー、モデルインスタンスなど、互いにどのように対話するかなど)を使用して非常に快適です。 ** DFRは、Djangoのクラスベースのビューのベースです。 DRFは慣用的なDjangoです。それはあなたがモデル形式、バリデーターなどを書いているように(まあ、慣用性のDjangoは慣用的なPythonに近い場所ではありません。あなたがPythonの専門家であるがDjangoの経験がないなら、あなたは最初は慣用的なDjango哲学に適合するのに苦労しているかもしれませんDRFも重要です)。 DRFには、Djangoのように多くの組み込み魔法の方法が付属しています。あなたがDjango Magical Methods and Philosophyを愛しているなら、** drf **はあなたのためだけです。

さて、正確な質問に答えるためだけに:

テイスティピー:

利点:

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

短所:

  1. 厳密に慣用的なジュンゴに従わない(マインドウェルパイソンとジュンゴの哲学はまったく異なる)
  2. あなたが大きくなると、APIをカスタマイズするのはおそらく少し難しい
  3. o-authはありません

DRF:

  1. 慣用性ジュンゴに従ってください。 (Djangoが裏返して、CBV、フォームなどに非常に満足していることを知っている場合は、間違いなく行ってください)
  2. ModelViewsetsを使用して、ボックス外の機能を提供します。同時に、Legsanializer、Apiview、GenericViewsなどを使用して、カスタマイズのためのより大きな制御を提供します。
  3. より良い認証。カスタム許可クラスを簡単に記述できます。非常にうまく機能し、重要なことに、サードパーティの図書館やOAuthで動作させることができます。 Django-Rest-Authは、Auth/SocialAuthentication/登録についてライブラリに言及する価値があります。 (https://github.com/tivix/django-rest-auth)

短所:

  1. Djangoをよく知らない場合は、これに行かないでください。
  2. 魔法!魔法を理解するのは非常に難しい時間です。なぜなら、それはDjangoのCBVの上に書かれており、本質的に非常に複雑であるからです。 (https://code.djangoproject.com/ticket/6735)
  3. 急な学習曲線があります。

個人的には、次のプロジェクトで何を使用しますか?

  • 今、私はもはや魔法やボックスの機能のファンではありません。彼らはすべて *多大なコストで来るからです。 *プロジェクトの時間と予算をすべて選択し、コントロールしていると仮定すると、落ち着きのないような軽量の何かから始めます(https://github.com/toastdriven/restless)(ThastypieとDjango-Haystackの作成者によって作成された(http://haystacksearch.org/))。そして、同じ問題については、おそらく/間違いなく、次のような軽量のWebフレームワークを選択します フラスコ。

  • しかし、なぜ? - 読みやすく、シンプルで管理可能な慣用Python(別名Pythonic)コード。より多くのコードですが、最終的には優れた柔軟性とカスタマイズを提供します。

    • 明示的なのは暗黙的なものよりも優れています。
    • シンプルは複雑よりも優れています。
    • 複合体は複雑よりも優れています。
    • フラットはネストよりも優れています。
    • スパースは濃いよりも優れています。
    • 読みやすさがカウントされます。
    • 特別なケースは、ルールを破るのに十分な特別ではありません。

DjangoとStastypieとDRFの1つ以外に選択肢がない場合はどうなりますか?

  • さて、Djangoを適切によく知っているので、** drfで行きます。 **
  • なんで? - イディオマティックジャニョ! (私はそれを愛していません)。より良いOAuthとサードパーティの統合(Django-Rest-Authが私のお気に入りです)。

では、なぜDRF/Thastypieを最初に選んだのですか?

  • ほとんどの場合、私はスタートアップや小規模企業と仕事をしてきましたが、これらは予算と時間が厳しいです。そして、迅速かつ使いやすいものを提供する必要があります。 Djangoはこの目的に非常によく役立ちます。 (Djangoがスケーラブルではないと言っているわけではありません。Quora、Disquss、YouTubeなどのWebサイトがあります。

私はそれがあなたがより良い決断をするのに役立つことを願っています。

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

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

現在、APIを露出させたい場合は、Django-frameworkをDjangoで使用する必要があります。

大企業がそれを使用しています。 Django-Rest-FrameworkはDjango Teamのコアメンバーであり、Django-Rest-Frameworkを維持するための資金を得ています。

Django-rest-frameworkには、3番目の芸術的なパッケージも膨大な数の成長しているため、APIをより簡単に簡単に構築できます。

DRFの一部は、Django Properでマージされます。

DRFは、Django-Tastypieよりも優れたパターンとツールを提供します。

要するに、それは十分に設計されており、手入れが行き届いており、資金提供されており、大規模な組織から信頼されている大規模なサードパーティアプリを提供し、Tastipieを介してより簡単で、より少ないボイラープレートなどを提供しています。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top