問題タブ [django-rest-framework]

基本的に私はこのようなモデルを持っています:

今、私は API がこのように PLAYLISTS を返すことを望んでいます...しかし、動画は PlaylistVideo モデルの POSITION でソートする必要があります

どうすればいいですか？

テストでDjangoRESTフレームワークを使用する一部のビューにデータを投稿するのに問題があります。django_webtestを使用してユーザーAPIをテストしています。次のコードで問題が発生しています。

問題は、2番目のテストの実行時にCSRFエラーが発生することです。Django REST Frameworkのドキュメントを見ると、セッションベースの認証を使用している場合にのみCSRFエラーがトリガーされることがわかりました。したがって、基本認証を試してみることにしました。これは、Djangoのドキュメントによると、REMOTE_USER環境変数を設定するだけで済みます。

ユーザーがこれらのページを表示することさえ許可されていなかったため（つまり、返された403のURLにアクセスした場合）、これはさらにうまく機能しませんでした。

私の質問は、django_webtestを使用して基本認証を適切に設定するにはどうすればよいですか？

次のような複数のクエリで複数のフィールドをフィルタリングしたい:

組み込みの方法はありますか、django-filtersを見ましたが、制限があるようです.APIビューで手動でこれを行う必要があると思いますが、フィルターでフィルターをフィルタリングすると、面倒です

APIに関連フィールドをどのように含めますか？

各Fooには、画像など、彼に関連する2つのBarがあります。

これらのバーをFooのリソースに表示するにはどうすればよいですか？

tastypieを使用すると、非常に単純ですが、DjangoRestFrameworkを使用するかどうかはわかりません。

そのため、よく調べてみると、REST URIにバージョン番号を埋め込むことは悪い習慣であり、悪い考えであるというのが一般的なコンセンサスのようです。

SOでも、これを支持する強力な支持者がいます。
例：APIバージョニングのベストプラクティス？

私の質問は、これを達成するためにdjango-rest-frameworkでacceptヘッダー/コンテンツネゴシエーションを使用するという提案されたソリューションをどのように達成するかについてです。

フレームワークのコンテンツネゴシエーションのようです
。http：//django-rest-framework.org/api-guide/content-negotiation/ は、受け入れられたMIMEタイプに基づいて目的の値を自動的に返すようにすでに構成されています。カスタムタイプにAcceptヘッダーを使い始めると、フレームワークのこの利点が失われます。

フレームワークでこれを達成するためのより良い方法はありますか？

このチュートリアルに従う：

http://django-rest-framework.org/tutorial/1-serialization.html

http://django-rest-framework.org/tutorial/4-authentication-and-permissions.htmlから

私はこのコードを持っています：

次に、APIのURLを開くと、次のエラーが発生します。

パラメータ「obj」の値としてisOwner.has_permission（）にNoneが渡されているようです。私は何が間違っているのですか？私は厳密にチュートリアルに従ったと思います。

私はdjango-rest-frameworkを調べてきました。

私の印象が正しいかどうか教えてください。

これは、Webアプリ用のRESTfulAPIエンドポイントの作成を支援することを目的としています。

実際のウェブサイトを生成するためのものではありません。rest_frameworkに含まれるクラスベースのビュー（APIView、generics.ListCreateAPIViewなど）は、Webページ自体へのレンダリングに使用されることは想定されていません。

つまり、このAPI用のURLのセットと、Webサイトにアクセスしてナビゲートするための別のセットがあることになっているということですか？

私は現在、バックエンドでDjango-Rest-Frameworkを使用し、フロントエンドでEmber.js/Ember-dataを使用するプロジェクトを作成しています。

この形式で、emberアプリからdjangoapiにクエリを返したいと思っています。

ここで、parameterは照会対象のモデルのフィールドであり、Xは検索する値です。

このような大まかなものが結果のクエリになるはずです

ここで、QUERY_PARAMS.dict（）は、次の形式の辞書を提供するDjango構文です。

** Djangoが期待するように、dictをキーワード引数に変換します。
したがって、上記の行は事実上次のようになります。

私はすでにカスタムビューとカスタムミックスインを使用してこれを機能させていますが、クエリ処理の実装が少し単純である可能性があり、これは非常に一般的なパターンとして私を襲うのではないかと心配しています。

Django用のライブラリがあるのか​​、それともDjangoの内部にあるのか、カスタムクエリセットコードなしでこれらの比較的一般的なクエリを処理できるのか、完全には理解していないのでしょうか。

正しい方向へのポインタをいただければ幸いです。

スティーブケイン

編集：

これは、整数クエリを処理するカスタムビューから取得した主要なメソッドです。何が起こっているのかを明確にするためにコメントを挿入しました。これがおなじみの/ひどい/素晴らしい/やや穏やかに大丈夫に見えるかどうか教えてください。

スティーブ

私は最近、RESTful Web API を実装するために、Django REST フレームワーク (および Django と Python - 私は RTOS/組み込みシステム担当者です!) を使い始めました。Google で解決できなかった問題はまだありませんが、この問題で数時間困惑しています。

私は、さまざまなデバイスに関連付けられているイベントをリッスンする組み込みシステムを持っています。これは、簡潔にするためにここで説明する通話を行う電話に似ています。電話には、番号と、それに関連付けられた (それが行った) 多数の通話があります。通話には、関連付けられた電話 (通話を行った電話) と作成時刻があります。呼び出しが発生すると、API に POST する必要があります。通話と発信元の電話番号をリッスンし、API に送信する組み込みシステムがあります。組み込みシステムは電話番号を知っているので、{"srcPhone":12345678}ではなく: を送信してほしいと思い{"srcPhone":"http://host/phones/5"}ます。これにより、組み込みシステムがすべての電話の主キーを知る必要がなくなります (または、電話を送信するたびに番号で電話を取得する必要がなくなります)。

Google と Django のドキュメントでは、自然キーを使用してこれを実現できることが示唆されました。私の試みは次のとおりです。

models.py

ビュー.py

serializers.py

http://host/calls/テストするために、番号 123456 の電話を作成します。次に、(CallList ビューを実行するように urls.py で構成されている)に POST {"srcPhone":123456} を送信します。これにより、/calls/ で AttributeError が返されます - 「int」オブジェクトには属性「startswith」がありません。例外は、rest_framework/relations.py (355 行目) で発生します。役立つ場合は、トレース全体を投稿できます。Relations.py を読むと、REST フレームワークは電話を番号で検索するのではなく、srcPhone 属性を URL であるかのように処理しているように見えます。これは通常は当てはまりますが、URL を提供するのではなく、自然キーで Phones を検索するようにしたいと考えています。ここで何を見逃したのですか？

ありがとう！

Django REST フレームワーク (2.1.16) には、null 可能な FK フィールドを持つモデルがありますtypeが、POST 作成要求400 bad requestでは、そのフィールドが必要であると示されます。

私のモデルは

シリアライザーは次のとおりです。

type次のようにシリアライザーに明示的に追加しようとしました

そしてそれは効果がありません。

http://django-rest-framework.org/topics/release-notes.html#21x-seriesから、バグがあったことがわかりますが、2.1.7 で修正されました。

FK フィールドを適切に処理するには、シリアライザーをどのように変更すればよいですか?

ありがとう！

更新：それが与えるシェルから

ただし、type=None なし:

どちらの場合でも、それは与えます