REST APIのベストプラクティス：クエリ文字列の引数とリクエスト本文の引数
上記の1〜2を選択する際のベストプラクティスと考慮事項は何ですか。
通常、コンテンツ本文は、サーバーとの間でアップロード/ダウンロードされるデータに使用され、クエリパラメーターは、要求された正確なデータを指定するために使用されます。たとえば、ファイルをアップロードするときは、本文に名前、MIMEタイプなどを指定しますが、ファイルのリストを取得するときは、クエリパラメーターを使用して、ファイルのプロパティでリストをフィルター処理できます。一般に、クエリパラメータは、データではなくクエリのプロパティです。
もちろん、これは厳密なルールではありません。あなたにとってより適切/効果があると思われる方法で実装できます。
クエリ文字列に関するウィキペディアの記事 、特に最初の2つの段落を確認することもできます。
あなたはPOST/PUTリクエストについて話していると思います。意味的には、リクエストの本文には、投稿またはパッチを適用するデータを含める必要があります。
URL（URI）の一部としてのクエリ文字列は、投稿またはパッチを適用するリソースを識別するためにあります。
次のセマンティクスは私のものですが、ベストプラクティスを求めました。もちろん、使用するWebフレームワークがこれをparametersに抽象化する場合は特に、経験則を使用しても機能するはずです。
あなたが最も知っている：
- 一部のWebサーバーでは、URIの長さに制限があります。
- CURLを使用して、リクエスト本文内のパラメーターを送信できます。
- データを送信する場所は、デバッグには影響しません。
以下は私の経験則です...
本体を使用する場合：
- 引数にフラットなキーと値の構造がない場合
- シリアル化されたバイナリデータなど、値が人間が読み取れない場合
- 非常に多数の引数がある場合
クエリ文字列を使用する場合：
- 引数がデバッグ中に表示したい場合
- コードの開発中にそれらを手動で呼び出すことができるようにしたい場合
curl - 引数が多くのWebサービスで共通している場合
- 既に
application/octet-streamなどの異なるコンテンツタイプを送信している場合
組み合わせて使用できることに注意してください。一般的なもの、デバッグ可能なものをクエリ文字列に入れ、残りをすべてjsonにスローします。