私はエンタープライズ Web アプリに取り組んでいます。私たちのアプリは、https のみで本番環境にデプロイされます。HTML 5 クライアントのみで使用される REST API を作成しています (他のクライアントでは使用できません)。
GET、PUT、DELETE は URL で ID を公開するため、私のチームはすべての残りの動詞に POST を使用することを決定しました。
私のチームが考えていることは、たとえ id が直接データベース ID でなくても、URL で公開されているデータのタイプを持っていることは良い考えではないということです。
誰もがGET、PUT、DELETEにPOST httpメソッドを使用し、http_methodをパラメーターとして渡し、パラメーターを使用してどの操作を行うかを決定することに同意しているようです。
これは、REST API に対して行う予定の唯一の違いです。どう思いますか？
GET の使用を避けると、キャッシュを使用できなくなります。本文でリソースの ID を非表示にすると、「リソースの識別」制約に違反する可能性が高くなります。これにより、リンク/ハイパーメディアがはるかに困難になります。
POST に限定すると、RESTful システムのメリットを享受することはほぼ不可能になると断言します。そうは言っても、HTML5 クライアントのみをターゲットにしていることを考えると、おそらく REST の利点のほとんどは必要ありません。Json-RPC を実行することは、おそらくニーズに十分すぎるほどです。
しかし、間違った安心感のために GET を捨てるのは良くないと思います。投稿の本文は、URI の ID と同じように仲介者によって簡単にアクセスできます。
スタックの利点を最大限に活用できるように、意図したとおりにHTTPを使用する必要があります。動詞が異なれば、意味も異なります。
POSTは必要なものをすべてGETするよりも安全であると感じることができますが、それは誤った前提です。
このデータを誰から保護していますか？真ん中の男？それがHTTPSが解決するものです。
エンドユーザーから保護していますか？アプリケーション全体をダウンロードして、いつでも好きなときにソースコードを調べることができる人はいますか？または、右クリックでページのソースを表示し、ペイロードがすべての栄光に配置されていることを確認しますか？または、ブラウザデバッガをオンにして、すべてのトラフィックを監視しますか？あなたはそれらの人々からそれを保護しようとしていますか？
POSTは誰からも何も隠しません。
httpsがあなたのために何をするかをほとんど説明しているので、おそらくこの投稿を見てください。したがって、質問は次のようになります。URLを誰から保護しますか？ブラウザの履歴にあるか、ユーザーの後ろに立っている人には表示されている可能性がありますが、回線を聞いている人には表示されない可能性があります。