1

REST (REpresentational State Transfer) について私が知っていることから思い出すと、サーバーで変更を呼び出すことを想定していない GET 要求のような特定の「安全な」HTTP メソッドがあります。

優れた RESTful API はたくさんありますが、そのうちの多くは、一定期間に作成できるリクエストの数を制限していることに気付きました。リクエストを追跡するにはサーバーで変更が必要になるため、GET リクエストを監視することは技術的に REST を壊すのではないでしょうか?

または、GET 要求を追跡するための完全に RESTful な方法はありますか?

4

3 に答える 3

2

ウィキペディアより

一部のメソッド (HEAD、GET、OPTIONS、TRACE など) は安全であると定義されています。つまり、これらのメソッドは情報の取得のみを目的としており、サーバーの状態を変更するべきではありません。つまり、ロギング、キャッシング、バナー広告の配信、Web カウンターの増加などの比較的無害な効果以外に、副作用があってはなりません。したがって、アプリケーションの状態のコンテキストに関係なく、任意の GET 要求を行うことは安全であると見なす必要があります。

これは、REST 要求にも当てはまります。

于 2013-07-08T21:17:38.493 に答える
0

使用状況の監視は、通常、アプリケーション層とは異なる層です。したがって、REST API は 1 つのことですが、使用状況の追跡は別のことです。

さらに、REST はアーキテクチャ スタイルですが、それに準拠するために現実を曲げるべきではありません。アーキテクチャを「壊す」ものを無視できる場合もありますが、その結果について考えた後にのみそうすべきです。建築に熱狂的であることは決して良い習慣ではありません...

于 2013-07-08T21:30:26.447 に答える
0

クライアントの観点から HTTP メソッドのセマンティクスを考えると、「安全な」セマンティクスの目的を理解しやすくなります。クライアントの観点からは、サーバーの状態を変更する意図なしにリクエストを発行しています。結果としてサーバーが状態の変更を行うことを選択した場合、それはサーバーの選択であり、クライアントはそれらの変更に対して責任があると見なすことはできません。

于 2013-07-09T02:52:18.990 に答える