16

私の HTTP API では、エンドポイントの 1 つがランダムに生成された値を返す必要があり、その値はエンドポイントの認証された呼び出し元に関連付けられます。現在、私は次の構造を持っています:

GET http://example.com/random-ticket HTTP/1.1
Authorization: Basic base64-encoded-basic-auth-value
Accept: application/json
Host: example.com

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/json; charset=utf-8
Date: Thu, 03 Oct 2013 07:25:56 GMT
Content-Length: 59

{"user-ticket":"Pfa42634e-1a2e-4a7d-84b9-2d5c46a8dd81"}

ランダムな値を取得するために GET 要求が発行されます。ただし、HTTP GET 呼び出しはべき等である必要があり、上記の実装はその規則に従っていません。一方で、メッセージ本文を空にして HTTP POST リクエストを発行してもよいかどうかはわかりません。

HTTPブックでこの種の操作を実行する正しい方法は何ですか?

4

4 に答える 4

16
  • 安全 => 呼び出しによってサーバーの状態が変化するかどうか。
  • べき等=>複数の呼び出しがサーバー上で同じ変更をもたらすかどうか。

したがって、問題は返されるデータではありません。むしろ、それはサーバーの状態です。したがって、この値をサーバーに保存している場合、状態が変化するため、GET には適していません。それ以外の場合は、返されたデータであれば問題ありません。http://stackoverflow.comへの呼び出しは、10 分間隔で呼び出すと、異なるデータを返します。

別の例として、現在の時刻を返すクロック サービスを見てみましょう。呼び出しを行うたびに異なる値が取得されますが、クロックの状態は個別に維持されるため、呼び出し自体によってサーバーの状態が変化することはありません。したがって、ここで GET を使用するのが適切な選択です。

于 2013-10-09T08:04:49.110 に答える
11

HTTP には、本文が空の POST の使用を禁止するものはまったくありません。

さらに、メッセージは、ボディ + ヘッダーである表現を運びます。あなたの場合、本文の長さは 0 で問題ありません。ヘッダーはユーザーを識別します。

ここでの議論を参照してください - http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0273.html

于 2013-10-09T07:55:41.903 に答える
5

保存されているサーバーの状態がないため、GET を使用したランダム ジェネレーターを使用しても問題はありません。同様に、パラメーターを受け取り、GET が呼び出されたときにそれらを追加する電卓を作成することもできます。cachable に関する質問は興味深いものですが、リソースは本質的にキャッシュされないため、乱数発生器には実際には当てはまりません。それでも、安全/冪等の方法で設計できるという事実は変わりません。

本文のない POST については、またはクエリ文字列で params を使用しても問題ありません。POST に関する重要な点は、サーバーに変更が生じる可能性があるということです。そうなることも保証されていませんが、GET のようにないとは限りません。内容が設定されているかどうかにかかわらず、変更がある可能性があるという事実は変わりません。たとえば、架空のリソース「\counter\increment」を想像してください。それに POST するたびに、\counter がインクリメントされます。ペイロードを送信していませんが、サーバーの状態を変更しているため、POST または PUT である必要があります。

于 2013-10-13T04:12:13.117 に答える
1

設計により、呼び出しをキャッシュできるPOSTため、この場合に使用する必要があります。GET空の投稿本文に関しては問題ありません。同様のシナリオが次の場所でも議論されています: POST with empty body

content-length も body もない POST は、Content-Length: 0 の後に何もない POST と同等です。たとえば、空のファイルをアップロードしたときに完全に発生する可能性があります。リソースは URL によって決定され、サーバーは本文が空であるかどうかを含め、本文の処理方法を認識している必要があります。実際、ここで問題が発生することはありません:-/

ウィリー

于 2013-10-09T10:30:21.713 に答える