92

サービスが、次のように使用できる機能を提供すると仮定しましょう。

GET /service/function?param1=value1&param2=value2

POST クエリで使用できると言うのは正しいですか?

POST /service/function { param1 : value1, param2 : value2 }

これら 2 つのクエリは同じですか? どのような場合でも 2 番目のバリアントを使用できますか? または、GET クエリと POST クエリの両方を使用できるとドキュメントに明示的に記載する必要がありますか?

4

8 に答える 8

101

次の理由から、重要な基幹業務アプリには POST 本文を使用します。

  1. セキュリティ - クエリ文字列と https で GET を使用すると、クエリ文字列をサーバー ログに保存し、参照リンクとして転送できます。これらは両方とも、サーバー/ネットワーク管理者と、ユーザーがアプリを離れた後に移動した次のドメインによって表示されるようになりました。そのため、顧客の名前などの機密 PII データを含むクエリを送信する場合、これは望ましくない場合があります。
  2. URL の最大長 - 大きな問題ではありませんが、ブラウザによっては長さに制限があります。したがって、クエリ、ページング、返すフィールドなど、URL に複数の項目がある場合....
  3. デフォルトでは、POST はキャッシュされません。キャッシングが望ましいと言う人もいます。ただし、キャッシュがタイムアウトする前に、その正確な顧客の正確なオブジェクトに対するまったく同じ一連の検索基準がどのくらいの頻度で発生するのでしょうか?

ところで、私は自分のフィールド名を公開したくないかもしれないので、返すフィールドも POST 本文に入れました。セキュリティはタマネギのようなものです。何層にもなっていて泣ける！

于 2016-02-16T23:24:13.313 に答える
74

レビューするだけRESTで、開発者がそれを作成するために従う必要がある特定のプロパティがありますRESTful。

レストとは？

ウィキペディアによると：

REST アーキテクチャ スタイルでは、アーキテクチャに適用される次の 6 つの制約が記述されていますが、個々のコンポーネントの実装は自由に設計できます。

  • クライアント-サーバー:サーバーはユーザー インターフェイスやユーザーの状態に関係しないため、サーバーはよりシンプルでスケーラブルになります。
  • ステートレス:クライアントとサーバーの通信は、リクエスト間でサーバーにクライアント コンテキストが保存されないため、さらに制限されます。
  • キャッシュ可能:クライアントがさらなるリクエストに応じて古いデータや不適切なデータを再利用するのを防ぐために、応答は暗黙的または明示的にキャッシュ可能であるかどうかを定義する必要があります。
  • 階層化されたシステム: 通常、クライアントは、エンド サーバーに直接接続されているのか、途中で仲介者に接続されているのかを判断できません。中間サーバーは、負荷分散を有効にし、共有キャッシュを提供することにより、システムのスケーラビリティを向上させる場合があります。
  • コード オン デマンド (オプション):サーバーは、実行可能コードを転送することにより、クライアントの機能を一時的に拡張またはカスタマイズできます。
  • 統一されたインターフェイス:以下で説明するクライアントとサーバー間の統一されたインターフェイスにより、アーキテクチャが簡素化および分離され、各部分が独立して進化できるようになります。(つまり、HTTP GET、POST、PUT、PATCH、DELETE)

動詞は何をすべきか

SO ユーザーのDaniel Vasalloは、 REST の理解: 動詞、エラー コード、および認証に関する質問で、これらのメソッドの役割をうまく説明しています。

次のようなコレクション URI を扱う場合: http://example.com/resources/

GET:コレクションのメンバーを一覧表示し、さらにナビゲーションできるようにメンバー URI を含めます。たとえば、販売中のすべての車をリストします。

PUT:「コレクション全体を別のコレクションに置き換える」と定義されている意味。

POST: ID がコレクションによって自動的に割り当てられるコレクションに新しいエントリを作成します。作成された ID は、通常、この操作によって返されるデータの一部として含まれます。

DELETE:「コレクション全体を削除する」と定義される意味。

だから、あなたの質問に答えるには：

POST クエリで使用できると言うのは正しいですか? ...

これら 2 つのクエリは同じですか? どのような場合でも 2 番目のバリアントを使用できますか? または、GET クエリと POST クエリの両方を使用できるとドキュメントに明示的に記載する必要がありますか?

単純な古い RPC API 呼び出しを作成している場合、処理サーバー側が両方の呼び出し間で違いがない限り、それらは技術的に交換可能です。ただし、呼び出しを RESTful にするためには、メソッドを介したエンドポイントの呼び出しには、メソッド (新しいリソースを作成するGET) とは別の機能 (リソースを取得する) が必要です。POST

補足:POSTリソースの更新にも使用できるようにするかどうかについては、いくつかの議論があります... 私はそれについてコメントしていませんが、その点で問題を抱えている人がいると言っているだけです。

于 2013-10-28T19:01:02.273 に答える
17

考えてみてください。クライアントが URI X に対して GET 要求を行うと、クライアントはサーバーに次のように伝えます。PUT リクエストは、「X にあるリソースを、このリクエストの本文で提供する新しいエンティティに置き換えてほしい」と言っています。DELETE リクエストは、「X にあるリソースを削除してほしい」と言っています。PATCH は、「この diff を提供します。X のリソースに適用してみて、成功するかどうか教えてください」と言っています。しかし、POST は次のように言っています。

リソースが POST を予期して何かを行うことをどこかに文書化していない場合、GET のように動作することを期待して POST を送信しても意味がありません。

REST は、基盤となるプロトコルの標準化された動作に依存しており、POST はまさに、標準化されていないアクションに使用されるメソッドです。GET、PUT、および DELETE リクエストの結果は標準で明確に定義されていますが、POST はそうではありません。POST の結果はサーバーに従属しているため、POST を使用して何かを実行できることが文書化されていない場合は、使用できないと想定する必要があります。

于 2013-11-02T19:59:15.747 に答える
3

REST では、各 HTTP 動詞にはそれぞれの場所と意味があります。

例えば、

  • GET は、URL で指定されている「リソース」を取得することです。

  • POST は、URL で指定された「タイプ」のリソースを「作成」するようにバックエンドに指示することです。POST 呼び出しの本文で、パラメーターまたは追加データを使用して POST 操作を補足できます。

あなたの場合、クエリを使用して情報を「取得」することに関心があるため、POST 操作ではなく GET 操作にする必要があります。

このwiki は、物事をさらに明確にするのに役立つ場合があります。

この助けを願っています！

于 2013-10-28T16:12:59.523 に答える