通常のサーブレットの代わりにJAX-RS RESTを使用する必要があるのはなぜですか？
GlassfishをWebサーバーおよびEJBコンテナーとして使用して、J2EEテクノロジーを学んでいます。 RESTについても学び、RESTのルールに準拠したアプリケーションを開発することに非常に興味があります。
私の最初のプロジェクトは、チャットクライアントを作成することです。ユーザーはWebページにアクセスし、JavaScriptを使用してWebページをダウンロードして、チャットクライアントを実行します（データをサーバーに投稿し、データもフェッチします）。 Webサーバーからのデータのポスト、およびデータのフェッチの呼び出しは、RESTfulインターフェースを介して行われます。現在、私は/ chatroom/getMessagesおよび/ chatroom/postMessage URIをリッスンするサーブレットを通じてこれを実行しました。
サーブレットを使用しないJAX-RSを使用してこれをRESTfulなサービスに変換しようとするときに遭遇するしわは、ホイールを再発明しているようなものです。サーブレット仕様では、このHTTPSessionオブジェクトを使用して、チャットバッファーのどこにいるかを簡単に追跡できるようにしました（そのため、/ chatroom/getMessagesにアクセスしたときにどのメッセージを送信するか）。しかし、完全にRESTfulにして、JAX-RSでPOJOを使用する場合（スタイルの観点からは、私は実際に好む）、ユーザーにトークンを渡し、それらを手渡すことで、セッション状態を再発明する必要があります。サーブレットを使用している場合に、自動生成されたセッションCookieが私のためにしてくれたように、話すたびにそれを私に返します。
なぜこれをJAX-RSで実装し、サーブレットを破棄する必要があるのですか？サーブレットとJAX-RSを混合するJAX-RSチュートリアルは（おそらく正当な理由で）見たことがないので、これはオプションではないようです。私が本当に知りたいのは、RESTを使用する際の説得力のある理由です。 RESTfulな方法でサーブレットを使用するだけでなく、何を購入するのですか？
安らかなAPIとしてのチャットサービスは、良いマッチです！
リソースベースのインターフェースは、今でも話し合う非常に重要な概念だと思います。上記の答えは4年以上前のものですが、正しくありません。
一般に、チャットサーバーインターフェイスをリソース指向のReST-ful APIとして構築することについては、実際には何も間違っていません。それは絶対的に有効であり、原則に非常によく適合しています。そこには、ReSTフルAPIの背後にある意図を強調するための非常に簡単な例としてこれを使用する例とチュートリアルのページさえあります。
なぜそれが良いのか
これは、サービスのようなフォーラムや「リアルタイム」チャットにすることができますが、この点は問題ではありません。つまり、ドメインモデルです。
例1（従来のリアルタイムチャット）：
より複雑なチャットサービスであっても、チャットルームを作成する必要があります。チャットルームはユーザー（ユーザーオブジェクト）にアタッチされ、チャットロビーはそれを囲みます（想定）。これで、ユーザーリソースまたはチャットロビーリソースを確認するか、追加のquery-paramsを介してチャットルームリソースをフィルタリングできます。これは完全に有効です。
チャットサービスドメインでモデル化されていない限り、クライアントが最近表示した投稿やこのようなものは、ウィキペディアで言及されているようなサーバー状態の一部ではありません。これは、クライアントの「セッション」状態です。クライアントは、チャットメッセージリソースのコレクションのどの部分を取得するかを通知します。
だから、それが一致しないと言う勇気はなんと!!チャットのようなフォーラムの場合は、さらに簡単です。
例2（チャットのようなフォーラム）：
"チャット" forumPostは、このforumPostへのコメントと同様にドメインオブジェクトです。確かに、一意のリソース識別子（URI）を可能にするために、一意の識別子が必要になります。これは上記の例と非常によく似ていることがわかります。これは一般的に良い例ですが、チャットを有効にしたいと考えています。
AOP監査を使用すると、作成および変更された時間が挿入され、承認を処理できます...
コアとなる側面は、この種のAPIによって、ドメイン、およびユーザー、コンシューマー、または相互作用するアプリケーション全般に関係する基本的な部分を理解することが必要になることです。
ステートレスかつステートフル：
原則を覚えておくことは本当に重要です。 ReSTに関するWikipediaのエントリとSTATELESS通信に関する段落は、ドメインオブジェクトの状態ではなく、クライアントの状態を対象としています。リソース、つまりドメインオブジェクトは、定義上、ステートフルです。参照されている段落は、ドメイン状態ではなく、セッション状態に関するものです。
エンタープライズソフトウェアを開発する場合は、境界と根拠をまっすぐにすることが重要です。
一言で言えば：
コメントや投稿、ユーザーは、安らかなAPIの完璧な例です。このため、チャットサービスは、最初はまったく問題ありません。シーケンシャルな識別子があっても間違いはありません。さらに進んで、リレーション（href）のリンクを使用し、リレーション属性（rel）を介してリレーションを定義してください。次に、クライアントはドメインタームを使用して正しいエンドポイントを使用できます。クライアントは、この手法（HATEOAS）を介して、ドメインオブジェクト自体の知識がなくてもオブジェクトのグラフ全体を探索できます。
これが古いエントリであるにもかかわらず、これが明確になるのに役立つことを願って、トピックはまだ完全に最近のものです。
サーバーに暗黙のセッション状態があると、基本的な RESTの概念 に対して実行されます。
クライアントとサーバーの通信は、リクエスト間でサーバーにクライアントコンテキストが保存されないことによってさらに制約されます。クライアントからの各要求には、要求を処理するために必要なすべての情報が含まれており、セッション状態はすべてクライアントに保持されます。サーバーはステートフルにすることができます。この制約は、サーバー側の状態がURLによってリソースとしてアドレス可能であることを必要とするだけです。
チャットクライアントがRESTアーキテクチャに適合しないと思います。とにかくそれを実行したい場合は、「チャットバッファ内の位置」をREST URLの一部にしてみてください（たとえば、メッセージに増分IDを指定すると、クライアントは/ chatroom/5を呼び出します）/getMessages/37は、メッセージ＃37の後にチャットルーム＃5のすべてのメッセージを取得します