HTTP 経由でアクセスする API を設計していますが、HTTP POST コマンドを URL クエリ パラメータのみで使用し、リクエスト本文を使用しない方法が適切かどうか疑問に思っています。
考慮事項:
- 「優れた Web デザイン」では、非べき等アクションを POST 経由で送信する必要があります。これは非べき等アクションです。
- URL にリクエスト パラメータが含まれていると、このアプリの開発とデバッグが容易になります。
- API は広範囲にわたる使用を目的としたものではありません。
Content-Length: 0本文のない POST リクエストを作成するには、ヘッダーを明示的に追加する必要があるなど、もう少し作業が必要になるようです。- また、本文のない POST は、ほとんどの開発者や HTTP フレームワークの期待に少し反しているようにも思えます。
リクエスト本体ではなく URL クエリを介して POST リクエストのパラメータを送信することには、他に落とし穴や利点がありますか?
編集：これが検討中の理由は、操作がべき等性がなく、取得以外の副作用があるためです。HTTP仕様:
特に、GET メソッドと HEAD メソッドは、取得以外のアクションを実行する意味を持つべきではないという規則が確立されています。これらのメソッドは「安全」であると見なされるべきです。これにより、ユーザー エージェントは、POST、PUT、DELETE などの他のメソッドを特別な方法で表現できるため、ユーザーは、安全でない可能性のあるアクションが要求されているという事実を認識できます。
...
メソッドには「べき等性」という特性もあります。つまり、(エラーや有効期限の問題は別として) N > 0 の同一リクエストの副作用は単一のリクエストの場合と同じです。GET、HEAD、PUT、および DELETE メソッドはこの特性を共有しています。また、OPTIONS メソッドと TRACE メソッドには副作用があってはならないため、本質的にべき等です。
ベストアンサー1
アクションがべき等性を持たない場合は、を使用する必要がありますPOST。そうしないと、後で問題が発生するだけです。GET、PUTおよびDELETEメソッドはべき等性を持つ必要があります。クライアントがサービスに対するすべての可能なリクエストを事前に取得していたら、アプリケーションで何が起こるか想像してみてくださいGET。これによってクライアントに見える副作用が発生する場合は、何かが間違っています。
POSTクエリ文字列はあっても本文がないのを送信するのは奇妙に思えることに同意しますが、状況によっては適切な場合もあると思います。
URL のクエリ部分は、現在のリクエストのスコープを制限するためのリソースへのコマンドと考えてください。通常、クエリ文字列はリクエストを並べ替えたりフィルタリングしたりするために使用されますGET( など?page=1&sort=title) が、 ではスコープも制限するのが理にかなっていると思いますPOST( など?action=delete&id=5)。