Quick design question: Is better to use a separate web app for a REST API(s) or not.
I currently have a Jersey REST API that serves well for machine to machine communication. Its relatively simple with GETS only. The structure is of a Jersey REST APi front end, a dao to the db store, and spring security to intercept the urls etc. This works well.
However I now need to create a web application to allow existing users the ability to login and monitor the use of their API, register for a user account, reset their credentials and change their subscription etc (plus more).
I’m wondering whether I should combine the two together, and share the same WAR file, as they both use the same back end databases etc. However, one is stateful, the other a stateless REST API requiring authentication per request…
So the approach I have adopted is to treat the stateful webapp as client to the REST API and do the following:
1) Treat the REST API as a separate web app.
2) Create the stateful web app as separate web app and use spring mvc or anything else for the front end. The persistent back end store will be the same for both. There will also be an admin component managed by spring role based security.
For the second webapp, I will allow the users to make example calls to the REST API (the first war just by clicking links and using their logged in credentials).
Does this approach seem reasonable? That is, one WAR for REST APIs, and a separate WAR for the stateful webapp.
I would appreciate any comments from those with more REST experience.
Making the REST API a separate application is a good approach, regardless of the other circumstances. You should have a common jar that contains the business logic, which you can include in all projects. That way you’ll be able to invoke business methods in both the API and other web projects without any duplication.