クイックデザインに関する質問：REST API用に別のWebアプリケーションを使用する方がよいでしょうか。Jersey REST APIを別のWebアプリケーションとして
私は現在、マシン間通信に適したジャージーREST APIを持っています。そのGETSだけで比較的簡単です。この構造は、ジャージーREST APiのフロントエンド、dbストアへのDAO、およびURLの傍受などのセキュリティを強化しています。これはうまくいきます。
しかし、既存のユーザーがログインしてAPIの使用状況を監視し、ユーザーアカウントを登録し、資格情報をリセットしたり、サブスクリプションを変更したりする機能を追加できるように、Webアプリケーションを作成する必要があります。
同じバックエンドデータベースなどを使用しているため、2つのファイルを結合して同じWARファイルを共有する必要があるのだろうかと思いますが、一方はステートフルで、もう1つはリクエストごとに認証が必要なステートレスREST APIです
1）別のWebアプリとしてREST APIを扱う：...
だから私は採用しているアプローチは、REST APIにクライアントとしてステートフルなWebアプリケーションを処理し、次の操作を実行することです。
2）ステートフルなWebアプリケーションを別のWebアプリケーションとして作成し、フロントエンドにspring mvcなどを使用します。永続的なバックエンドストアは、両方で同じになります。また、春のロールベースのセキュリティによって管理される管理コンポーネントもあります。
第二のWebアプリケーションのために、私は、ユーザーが一例は、（単にリンクをクリックし、それらの資格情報でログインして使用することにより、第1戦）REST APIへの呼び出しを行うことができます。
このアプローチは妥当と思われますか？つまり、REST API用の1つのWARと、ステートフルなWebアプリケーション用の別のWARです。
RESTの経験が豊富なユーザーからのコメントをいただければ幸いです。
ご意見ありがとうございます。これは私が考えているものですとしてだけで明確にするために、あなたは別のアプリケーション間で共有するために、単一の戦争のWebアプリケーション内で共有するために、複数のjarファイル、または複数のjarファイルをお勧めですか？再度、感謝します。 – user983022
は、私は時間を節約し、短いAPIを短絡の間違いに取得しないことを追加し、別のアプリケーション – Bozho
全体のjarファイルを共有しています。 APIとのやりとりが必要なものは、APIを使用して行う必要があります。私の仕事では、コードを共有しないことで明示的に分けています。私はコードを共有する必要がある場合は、それが最も可能性が高い、すでに存在していないAPIに追加すべき機能があることを意味します。 – Casey