ステファン・ティルコフによる話がここにあります、彼はそのコアでRESTアーキテクチャを説明しています。すべてを見たわけではありませんが、RESTの5つの原則（スライド12〜19）について話している部分で、リソース（つまり、URI）を介して状態を維持することに言及しています。彼の例はショッピングカートです。通常、ショッピングカートの状態はセッションで維持されますが、セッションを同僚に「送信」することはできませんが、リソースを送信することはできるため、これは誤ったインターフェイスの実装であると彼はコメントします（ここで言い換えます）。状態。これにより、カート内のすべてのアイテムが含まれます。この概念は興味深いものだと思いました。この種のアーキテクチャの実装について実際に説明している追加情報、リソース、リンク、ビデオなどを誰かが持っているかどうか疑問に思いました（できればJavaで）。ありがとう！
編集：
申し訳ありませんが、ここで簡単に編集します。REST実装自体に関する情報が必要なことではなく、実際にリソース状態をセッション/db状態よりも広範囲に使用することの欠点/利点が必要です。
セッション状態の不利な点の最も明確な説明の1つは、RESTを紹介するRoyFieldingの論文から直接得られます。（強調は私のものです）
次に、クライアント/サーバーの相互作用に制約を追加します。セクション3.4.3（図5-3）のクライアント-ステートレス-サーバー（CSS）スタイルのように、通信は本質的にステートレスである必要があります 。サーバー には、リクエストを 理解するために必要なすべての情報が含まれている必要があり 、サーバーに保存されているコンテキストを利用することはできません。
したがって、セッション状態は完全にクライアント上に保持されます。
この制約は、可視性、信頼性、およびスケーラビリティの特性を誘発します。
監視システムは、要求の完全な性質を判断するために単一の要求データを超えて調べる必要がないため、可視性が向上します。
部分的な障害からの回復作業が容易になるため、信頼性が向上します[133]。
リクエスト間に状態を保存する必要がないため、サーバーコンポーネントがリソースをすばやく解放できるため、スケーラビリティが向上します。また、サーバーがリクエスト間でリソースの使用を管理する必要がないため、実装がさらに簡素化されます。
Royはさらに、この制約の適用は設計上のトレードオフであり、この選択には悪影響があると述べています。
アプリケーションアーキテクチャでセッション状態を使用しないことを選択すると、2つの方法のいずれかでショッピングカートなどを維持することになります。カートはクライアントアプリケーションによって完全に維持されるか、リソース状態として保存されます。何かをリソースにするのは、それがURIによって識別され、インターフェースの標準動詞によって操作できることです。カートをリソースとして保存する場合は、Stefanが言うように、リソースへのリンクを同僚に送信できます。このアプローチでは、他のリソースと同じようにショッピングカートを実装できます。
そして、この種のもの（できればJavaで）のアーキテクチャの実装について実際に議論している追加の情報、リソース、リンク、ビデオなどを誰かが持っているかどうか疑問に思いました。ありがとう！
要するに、「フレンドリーなURLコントローラー」で十分でしょう。HttpServletRequest#getRequestURI()またはを抽出HttpServletRequest#getPathInfo()し、RESTデータを使用してjavabeanを作成し、コマンドパターンを使用してそれに応じてアクションを実行し、最後に問題のJSPページに転送してデータを表示するフィルターおよび/またはサーブレットを作成します。
URLの長さは、使用するWebブラウザとWebサーバーに応じて特定の境界線に制限されていることに注意してください。255文字を超えないようにすることをお勧めします。本当にURLにさらに多くの情報を保存する必要がある場合は、GZippingとBase64encodingを検討し、URLの末尾に。のように追加しますhttp://example.com/cart/2j34hfg5jh2g5bnvcnb2vc452。URLが読みやすくなるわけではありませんが、機能し、多くの情報を渡すことができます。