15

私はこのアドバイスを見てきました...

理想的には、Web は REST 原則に従い、完全にステートレスであるべきです。したがって、各ユーザーのナビゲーション履歴を保持する必要なく、1 つの URL で 1 つのリソースを識別する必要があります。

...そして、ウィキペディアのページhttp://en.wikipedia.org/wiki/RESTを読んだところ、本当に良さそうですが、実際に実装する方法がわかりません。私は MVC ではなく ASP .NET Webforms で作業しています。

たとえば、私が構築しようとしているアプリケーションでは、ユーザーに何かを許可する前にログインする必要があります。T と C を受け入れて、基本的な詳細が変更されていないことを確認するなど、多くの有用なことを実行できるようになる前に、ジャンプしなければならないいくつかのフープがあります。最後に、BuyAProduct のように本当にやりたいことができるようになります。

私には (私はリッチクライアントの非常にステートフルな世界から来ました) 彼らが何をしたかを記録し、そこから彼らが何をすることが許されているかを推測するために状態が必要だと思われます。BuyAProduct URI をブックマークすることを (たとえば) サポートする方法がわかりません。彼らがブックマークに到着したとき、彼らがログインしたかどうか、T と C に同意したかどうか、基本的な詳細を忠実にチェックしたかどうかをどのように知ることができますか?

アプリがステートレスであるというアイデアが気に入っています。理由の 1 つは、「ユーザーが [戻る] ボタンと [進む] ボタンをクリックすると、一体どうすればよいのか」という問題を完全に解決しているように見えるからです。どうすればそれを適切に機能させることができるのかわかりません。私はこれについて本当に基本的な何かが欠けていると感じています。

4

5 に答える 5

23

このアドバイスは、アプリをステートレスにすることを示唆しているのではなく、アプリ内のリソースをステートレスにすることを示唆しています。つまり、「www.mysite.com/resources/123」というページは、アクセスしているユーザーやログインしているかどうかに関係なく、常に同じリソースを表します。

(ログインしていないユーザー アクセスを拒否する可能性があるという事実は、別の問題です。要点は、Uri 自体が機能するためにユーザー固有のデータに依存していないということです。)

たとえば、このルールに違反する種類のサイトは、製品ページに移動し、Uri を友人にメールで送信し、それをクリックすると、「申し訳ありませんが、セッションの有効期限が切れました」という行に沿ったメッセージが表示されるサイトです。 」または「この製品は存在しません」など。これが発生する理由は、Uri にサイト上のユーザーのセッションに固有のものが含まれており、別のユーザー (または後で同じユーザー) がリンクを使用しようとすると、リンクが無効になるためです。

したがって、アプリケーションには何らかの形の状態が常に必要ですが、その状態が実装されている場所が重要な要素です。

少し光を当てるのに役立つことを願っています!

于 2010-06-10T16:35:18.067 に答える
12

Web フォームを作成したい場合、それはすばらしいことです。REST を実行したい場合は、それもクールです。ただし、すべての神聖なものを愛するために、Web フォームを使用して REST の原則を守ろうとしないでください。

この点をさらに明確にするために、WebForms が基づいている概念モデルは、Web を抽象化するものであるため、Webforms が REST にとって賢明な選択であるとは思いません。VB 開発モデルをエミュレートするために作成されました。

REST は、HTTP と Web アプリケーションの分散型の性質を取り入れています。2 つのアプローチには互換性がありません。

于 2010-06-11T00:01:47.720 に答える
3

リソースの状態を維持しても問題ありません。「ステートレス禁止」は、セッション状態を参照するだけです。

以下は、 Roy Fielding の影響力のある REST 派生からの抜粋です。

次に、クライアントとサーバーの相互作用に制約を追加します。通信は、セクション 3.4.3 (図 5-3) のクライアント-ステートレス-サーバー (CSS) スタイルのように、本質的にステートレスでなければなりません。サーバーには、要求を理解するために必要なすべての情報が含まれている必要があり、サーバーに保存されているコンテキストを利用することはできません。したがって、セッション状態は完全にクライアント上に保持されます。

于 2013-06-01T23:16:39.670 に答える
1

クッキーはあなたの質問に対する答えのようです。Cookie を設定する .net 認証プロバイダーを使用できます。これにより、アプリケーションは Cookie を確認し、何かを購入する場合にその存在を要求できます。

あなたが試して避けたいことは、サーバー上にそれらの状態表現、別名セッションクッキーを保持することです。これにより、スケーリングがより困難になります。

于 2010-06-11T08:06:20.303 に答える
1

つまり、REST は、ステートレス プロトコルを介したステートフルな通信に関するものです。REST がステートレスだというわけではありません。WebForms を使用すると、リクエスト間で状態を保持できます。なぜそれが必要なのですか？クリックするたびに基になるリソースを更新することなく、上/下ボタンを使用してリストのアイテムを並べ替えるなどのことができます。あなたはそれを必要としません。リソース表現を PUT して正しく見えるようにするか、JavaScript を使用して表現を編集し、満足したら最後に PUT を実行することができます。(POST ではなく PUT を使用したことに注意してください。実際に行っているのは、将来の GET が正しい状態を取得できるように表現を置き換えることです。)

WebForms はすべてに POST を使用します。新しいアイテムを作成していて、それがどこにあるかわからない場合にのみ、URL に POST する必要があります。URL がわかっている場合は、PUT を使用して作成または置換する必要があります。ショッピング カートなどの中間ステップが必要な場合は、それらの中間ステップのリソース表現を作成する必要があります。ブラウザーとサーバーは、相互に完全な表現を渡すことによって通信します。これは単純な要求/応答メッセージの受け渡しです。

WebForms はこれを推奨していません。WebForms で RESTful システムを構築することはできますが、デフォルトのモデルではそれを避けて RPC アプローチに移行することになります。これには 2 つの方法が考えられます。フロント コントローラー(この場合、MVC を実際に検討する必要があります) と、ほぼすべてに .ashx ファイルを使用する方法です。ポストバック モデルは、実際の WebForms/.aspx で真の REST を実行するという実際の希望を完全に消し去ります (つまり、PUT と DELETE は常に POST であるため、REST モデルは機能しません)。

于 2010-06-11T06:55:52.273 に答える