Jersey REST API as Standalone Web Application

Quick design question: is it better to use a separate web app for the REST APIs or not.

I currently have a Jersey REST API that is good for machine communication. It's relatively easy with GETS. The framework consists of front end REST APi in Jersey, dao in db store, and spring security for intercepting urls, etc. It works well.

However, now I need to create a web application to allow existing users to log in and control the use of their APIs, register for a user account, reset their credentials and change their subscription, etc. (plus more).

I am wondering if I should merge the two together and share the same WAR file since they both use the same background databases etc. However, one of them is stateful, the other is a stateless REST API, requiring authentication for every request ...

So, the approach I have taken is to treat the stateful webapp as a REST API client and do the following:

1) Treat REST API as a standalone web application.

2) Create a stateful web app as a standalone web app and use spring mvc or whatever for frontend. The permanent storage at the back end will be the same for both. It will also create an administrative bean managed by spring role-based security.

For the second webapp, I am allowing users to make calls to the REST API examples (first war by simply clicking links and using their registered credentials).

Is this approach sane? That is, one WAR for the REST API and a separate WAR for the stateful webapp.

I would appreciate any comments from those with more REST experience.

+3


source to share


1 answer


Creating a REST API for a standalone application is a good approach, regardless of other circumstances. You should have a common jar that contains business logic that you can include across all projects. This way you will be able to call business methods both in the API and in other web projects without duplication.



+2


source







All Articles