Web での REST 原則の適用を検討することによって。私はRESTのケーススタディを行っていますが、主にUniformインターフェースに疑問があります。Uniform Interface には、HTTP 動詞 (get、post、put、delete、head など) の代わりに単一の PROCESS しかないと想定しています。従来の HTTP 動詞を使用したこの種のプロセスの潜在的な結果はありますか?
1 に答える
0
従来の HTTP 動詞を使用したこの種のプロセスの潜在的な結果はありますか?
いくつかあります。
考慮事項の 1 つは安全性です。RFC-7231 では、セーフはこのように定義されています。
定義されたセマンティクスが基本的に読み取り専用である場合、リクエスト メソッドは「安全」と見なされます。つまり、クライアントは、安全なメソッドをターゲット リソースに適用した結果として、オリジン サーバーの状態が変化することを要求せず、期待もしません。
したがって、PROCESS が GET のような安全な動詞である場合、読み取り専用 Web に類似したものになります。HTTP 仕様では、HEAD と OPTIONS (最適化された読み取り) および TRACE (デバッグ ツール) も定義されています。HTML がこれらのメソッドのサポートを含まない非常に成功したハイパーメディア形式であることを考えると、HTML 自体は特に批判的ではないことが示唆されます。
PROCESS を安全に指定すると、REST のスケーリングの利点がすべて保持されます。しかし、その有用性は限られています。クライアントはコンテンツを消費できますが、作成することはできません。
一方、PROCESS が安全でない場合、多くのユース ケースをサポートできなくなります。コンポーネントは、PROCESS の呼び出しがサーバーに悪影響を及ぼさないと想定できなくなったため、コンテンツのプリフェッチはオプションではなくなりました。同じ理由で、クロールはもはやオプションではありません。
おそらく、Web のメソッドの仕組みに注目する価値があります。どのリンクにどのメソッドが適しているかを説明するのは、ハイパーメディア形式です。したがって、ハイパーメディア形式自体のメソッドに制限を定義することで、いくつかの問題を回避できる可能性があります。これは、問題のメディア タイプを消費できる任意のコンポーネントに同じ情報を伝える別の方法です。
ただし、少なくとも 2 つの考慮事項があります。まず、リンク内の情報は、そのメディア タイプを認識しているコンポーネントだけが理解できるということです。Web では、ほとんどのコンポーネントはメディア タイプに依存しません。html のキャッシュは、json のキャッシュと jpeg のキャッシュのように見えます。
次に、リンク内の情報はアウトバウンド側でのみ利用可能です。REST はステートレスを意味します。リクエストの処理に必要なすべての情報がリクエスト内に含まれています。これは、通信障害の処理に必要なすべての情報をリクエストに含める必要があることを意味します。
たとえば、http 仕様ではidempotentが定義されています。
要求メソッドは、そのメソッドを使用した複数の同一の要求のサーバーに対する意図された効果が、単一のそのような要求の効果と同じである場合、「冪等」と見なされます。
このプロパティは、中間コンポーネントが信頼できないものに沿ってリクエストを転送し、サーバーからの応答を受信しない場合に重要です。メッセージが失われたのか、単に遅いだけなのかを知る方法はありません。また、失われた要求メッセージと失われた応答メッセージを区別する方法もありません。
要求にべき等であるという情報が含まれている場合、仲介者は、クライアントにエラーを報告するのではなく、メッセージをサーバーに再送信できることを認識します。
これを http での POST の正しい処理と比較してください。POST リクエストにはべき等マーカーがないため、コンポーネントは、メッセージの再送信が望ましい効果をもたらすことを知りません (これが、フォームを 2 回 POST しようとすると、通常、Web ブラウザーが警告を表示する理由です)。
1 つの方法に自分を閉じ込めることで、選択の余地が生じます。仲介者によるエラー回復をサポートしますか? または、冪等でない書き込みをサポートする柔軟性が必要ですか?
于 2016-08-04T16:08:08.440 に答える