2

これは非常に基本的な質問のように思われるため、以前に尋ねられた場合は申し訳ありません。有用なリソースの方向を教えてください。

したがって、データを取得するための RESTful サービスがあります。ただし、RESTful サービスでは、取得を行うために一定量のデータが必要です。このデータは、「ユーザー コンテキスト」データとして大まかに要約できます。ユーザーに関する情報 (呼び出し元のアプリケーションによって保存されているか、以前に別のアプリケーションから取得されたか) は、サービスが取得を実行するために使用する必要があります。

REST は意味的に機能するため、何かを取得するための正しい動詞 (HTTP メソッド) は GET 要求です。私が見たほとんどの GET リクエストの例は、少量のデータしか使用せず、データは URL で渡されます。しかし、検索するために大量のデータを必要とするサービスの領域に入ると、そのすべての情報を URL に入れるのは間違っているように思えます。それだけでなく、特定のコンポーネント (多くの場合 255 文字程度、IIRC) によって適用される URL の長さには既知の制限があります。

利用可能なオプションは次のようです。

  • POST を使用して、要求本文でデータを送信します。ただし、サービスに何も更新することを要求しておらず、取得のみを要求しているため、これはセマンティックではありません。
  • 情報の大部分 (私の場合は「ユーザー コンテキスト」) を HTTP ヘッダーに入れます。ただし、ヘッダーはデータではなくヘッダーに使用する必要があるため、これは「間違っていると感じます」。
  • 複数の URL でデータを送信する複数の要求を行います。ただし、サービスはリクエストを結び付けるために何らかの状態を維持する必要があるため、これはステートレスの目標を破るようです。
  • データをデータベースに書き込み、サービスにキーを渡してそこからデータを取得します。ただし、これにより、要求が自己完結型ではなくなり、パフォーマンスのボトルネックも発生します。

別のオプションはありますか？ここでのベストプラクティスは何ですか?

4

1 に答える 1

2

仕様による制限はありませんが、HTTP ヘッダーは、リクエスト パス (URL) と同様に、有効な長さが制限されています (以下のリンクを参照)。

サーバーの制限を調整または削除することはできますが、サードパーティ システム (HTTP キャッシュなど) との互換性を維持することがはるかに難しくなり、任意の HTTP クライアントがこれらの事実上の制限を超えることをサポートするという保証もありません。

サーバーに大量のデータを互換性を持って送信する唯一の方法は、リクエスト本文を使用することです。標準の HTTP 動詞のうち、ボディを持つことができるのは POST および PUT リクエストのみであり、それらのうち、PUT は達成しようとしているものと意味的に互換性がありません。

必要なすべての情報が常に URL または要求ヘッダーに収まることを保証できない限り (前述の制限を考慮して)、POST 要求を介してこの必要性を表現するように REST API を設計する必要があります。

POST 動詞がサーバー上で何かを変更または作成するためだけに使用されるというのは誤解です。実際には、他の動詞が冪等である (副作用がなく、重複した要求を実行すると結果が重複する) ため、POST はこれらのニーズを満たすことができる唯一の動詞ですが、一般的に、POST はキャッチオールです。他の動詞がうまくいかないことは何でも。

POST は、GET の制限を回避できない場合に、検索 (より多くの場合はリダイレクト) または処理動詞として合法的に使用できます。Cache-Controlやなどのキャッシュ関連の応答ヘッダーを設定することで、POST 応答を GET のように動作させることもできますExpires。

于 2015-01-09T21:02:24.607 に答える