Exposing Spring services over http - need recommendations

Posted Tue, 08/02/2011 - 17:39 by shalom
, , ,

Hi

We have a spring 3 application running on tomcat and secured with spring security (form login). the spring beans are exposed with HttpInvoker and our native client is a java applet. using HttpInvoker from the java applet is seamless, when calling the applet page, if a user is not authenticated spring security redirect to a login jsp. from now on the java plugin on the client side knows how to put the http session id on the http header for every HttpInvoker call.

Now, we want to expose some of our services in a more friendly way then HttpInvoker and of course REST/JSON is the first thing that comes in mind because our future clients could be written in any language, most probably .net clients.

So we'd like to hear experienced recommendations of what's the best REST framework to integrate with spring and spring security, is it resteasy, jersey,CXF,restlet, spring mvc.

Thank you.

 

‹ JVM parameters tuning question. Getting local host via InetAddress.getLocalHost() under Linux ›

Comments

by zvika - 08/02/2011 - 17:53

I did JSON with SpringMVC, with seialization customization via jackson annotations. see:

http://www.tikalk.com/java/exposing-spring-services-consumption-gwt-front-end

(ignore method 1)

by yanai - 08/02/2011 - 22:04

Here are my point of views:

  1. I prefer not to go with Spring-MVC as my REST implementation, since I prefer to go with the standard JAX-RS (which I find it a good standard). All the others follows the JAX-RS so its fairly easy to move from one implementation to another - I did it myself and moved from Jersey to RESTEasy.

  2. Regarding Spring Security - If you are using form authentication, than it does NOT really matter which implementation you choose of web service. You can use HTTPInvoker (as you already doing) REST implementation (no matter which of the above you choose) even SOAP implementation - They all work above HTTP. All you need to do is to take the cookie you get back from the login form request, and put it on the following HTTP request - no matter which programing model you choose.

 

 

 

by shalom - 09/02/2011 - 12:41

Thank you guys,

personally I don't mind using something that is not a standard like Zvika's spring-mvc example if it fulfils my needs and it feels like spring-mvc may have better integration with spring, isn't it?

 

Yanai, can you say why do you prefer resteasy over jersey? any real reason?

 

we have a lot of services to expose that with HttpInvoker transfer a lot of complex java objects, I think we'll have to try at least two of those frameworks and see which is better for us.

 

about spring security login, we already did what you said Yanai, when we wanted to use HttpInvoker outside of the java applet we had to manually login,extract the coockie and inject it to every HttpInvoker call, which is something that looks a little primitive to me but I didn't see any other way. for example I would expect the HttpInvoker client factory to be able accept credentials and release me from the manual login.

 

 

by yanai - 09/02/2011 - 15:09

 It was two years ago, and the reasons may not relevant anymore (I tried Spring-DM and it had better integration at that time with Jeresy). My point is that, you can start with one of the framework, and if notice that its not good enough, you can just move to another without changing all the annotations all over your services. That is the real value of the spec. If Spring will come short for you, it will be more painful. Please the other ones integrate with Spring very good - All the beans with JAX-RS annotations are registered automatically as resources in the frameworks.

Regarding the HttpInvoker client - I guess you may try to extend the ProxyFactoryBean...  

 

 

by zvika - 09/02/2011 - 17:30

don't know about the security issues -

but regarding rest implementation - imo, it's totally a question of preference.

I tend to think that the glory days of Java framework spec are gone, and if Spring has a functional implementation, I'd go with it since it was probably used and tested more than the average, spec or non-spec. I would much rather go with one implementation that does the job for me and that is extensible, has big community, listens to bug reports etc. (and I am definitely not saying RestEasy or Jersey don't) - than the option of switching implementation if something break. At the end of the day - I just need one, and I need it to work.

 

If the Spring implementation would fail to do what you want, it is true that you'd be in a bit of a pickle, as they say, but let's get real - Spring's implementations are usually (here too, from my experience) robust, extensible, sensible and dev' friendly.

 

...just my opinion, and is debatable. I totally respect Yanai's take