REST / hipermedia APIの設計、特にdjango-restフレームワークを使用した実装に関してアドバイスを求めたいと思います。
一般的な「エンティティ」の例の代わりに、よりありふれた「ドキュメント」エンティティを使用します。
質問1。
GET /document/?[query]
ドキュメントのリストを取得します。問題は、「ドキュメント」には数十の属性があり、多くの場合、クライアントは少数（特にこの検索）のみを気にすることです-応答のサイズは数回（最大10回）のように異なる可能性があり、サーバーもクエリの方が速い場合があります。また、スキーマがないことを好むことにも言及する必要があります。
私は次のようなサンプルを見つけました
GET /document/attr1, attr2../?[query]
これは、RESTにまったく影響しません。
別の記事では、Content-Types（実際にはリクエストの場合はAccept）を使用することを提案していましたが、例が欠落していて、まだ複雑な感じがあります。何かのようなもの：
Accept: application/json; attrs="attr1,attr2"
これがHTTPのセマンティクスを尊重しているかどうか、またそのようなメディアタイプパラメーターの使用が適切かどうかはわかりません（結局のところ、リソースの別の表現が必要です-一部の属性はフィルターで除外されています）。
質問2。
上記が多かれ少なかれ許容できる解決策である場合、カスタムメディアタイプ属性の解析に関してdjango-restに何か準備ができているかどうか疑問に思います。私が彼のドキュメントで見ることができることから、メディアタイプパラメータは個別に解析（または処理）されません。
編集
いくつかの追加情報：アプリケーションの大部分はOLTPです（キャッシュ可能ではありません）。アーキテクチャは静的ファイルを備えたJSONサーバー、JSヘビークライアントです。
編集2
実際、検索の性質上、新しい（揮発性の）リソース（結果）の作成であるという意見もありましたので、POST方式の方が適しています。これにより、議論中の問題が解消されます。作成したエンティティ（結果）に問題があります。永続化する必要がないためですが、これは必須ではないと思います。問題は、「Location」ヘッダー（偽のURL、Locationヘッダーなしなど）に何を入れるかです。私にとって唯一の一貫した動作は、まさに私がやりたくないことです。検索POSTは検索を実行し、結果をサーバー側に保存して、それにリンクする201を返します。ただし、これは不当な永続性の負荷です...
ブラウザのテストに関して、MIMEタイプtext / htmlは、検索のためのユーザーフレンドリーなフォームを提示する場合があります。