Implementing a public API in java. What framework?

Question

Hi everyone,

I'm currently working on implementing the public API of our web application. The application is written in Java.

This is a financial application deployed on Tomcat. My users can manage their sales, customers, purchases, inventory, etc. It's a pretty huge application. The font-end is written in Java/GWT. The backend is written in Java s well. We use the GWT-RPC mechanism between.

What we want is to provide a way to access the financial data (read + write) via a public API. This way, developers will be able to better integrate their application (like a payroll application).

We don't use any framework. No Spring, grails, whatever. Also, no Hibernate, JPA, etc. It's a pretty old app, with lot of proprietary code for the ORM, XML-> javabean. authentication, etc. Cannot change all of that as the application is already in production and it just works that way.

The API infrastructure will be on a different sub-domain and on a different server.

The API should use Oauth to authenticate the users.

I looked into Grails, Play!Framework and Restlet to achieve my goals

Does anyone have some thought on them? Am I going in the wrong way with those frameworks? Is there another framework to look at?

Thank you all

Answer 1

I have some thoughts yes. Financial applications tend not to use OAuth. To be clear: nobody with vulnerable data uses OAuth. That includes privacy, medical and financial data.

Answer 2

I'd recommend following the example of Amazon and such and expose that API as web services, without regard for UI. Your have a further choice about SOAP versus REST. I think you'll find that REST will be simpler for your clients, because they only need to know about HTTP.

This doesn't mandate the use of any frameworks if you choose not to. The back end will work regardless of whether or not you use Spring, Hibernate, Grails, etc.

You'd have to rework the application you have to call the services if you wanted true reuse, but it might be worth it in the long run. Both your UI and clients would be using a common back end API that way.

Answer 3

If you're going to expose read/write to a Java-based financial services application over the public internet, I would look at SOAP-based web services with JAX-WS as there is a pretty mature security spec in WSS and the API is relatively easy to use and may not require much in the way of changes to your existing app.

REST is perceived as easier in general but for this type of application you might find your target audience is more familiar with SOAP anyway. All depends who your target audience is and exactly what you're trying to achieve, but worth considering.

Answer 4

What kinds of deployment environments do you expect to use this API. That might narrow it down, the standard answer if you have absolutely no idea who your client is, is still supposedly SOAP (since so many people know and accept the buzzword).