I'm Solomon Duskis, NYC consultant and a Java/J2EE guy. I work at Sungard Consulting Services in NYC. The postings on this site are my own and do not necessarily represent the positions, strategies or opinions of my employer. Solomon is a DZone MVB and is not an employee of DZone and has posted 22 posts at DZone. You can read more from them at their website. View Full User Profile

Spring REST Framework Potential

12.10.2009
| 11249 views |
  • submit to reddit

Where is the Spring REST framework going? The Spring Framework has always been about choice, integration and convergence, and the REST over Spring @MVC should is no different. The world at large has criticized Spring's REST attempts as an unnecessary "me too" architecture; Spring 3.0 indeed does copy a lot of the JAX-RS design, but uses Spring MVC annotations instead of the JAX-RS standard. Why did the Spring folks do that instead of using the JAX-RS annotations?

Sure the Spring @MVC framework's annotations were there first, but the REST capabilities have been playing catchup with JAX-RS. The Spring Framework's emerald rockstar -- Arjen Poutsma gave the following reasons for Spring MVC's REST decision in response to my DZone article on Spring MVC 3.0 REST:

  • JAX-RS annotations overlap with the Spring MVC annotations introduced in 2.5.
  • JAX-RS is semantically different than Spring MVC, i.e. request-scoped by default vs. singleton by default
  • JAX-RS focuses on RESTful web services, while historically Spring MVC had a focus on web sites (though that changed in 3.0)
  • We also investigated options to add Spring DI to JAX-RS objects, but since all major JAX-RS implementations already had Spring support, there was little added value there.

That sounds like : 1) there was overlap 2) there were some technical incompatibilities 3) we do websites, not REST 4) JAX-RS implementations already integrate with Spring. That doesn't really answer the question: "How can Spring MVC's take on REST help me kick a$$?"

 

Spring MVC REST Potential Direction

As I said, I do believe that there's excellent unrealized strategic potential for Spring MVC's REST infrastructure (i.e. using these improvements Spring MVC will help you kick a$$). I don't think think the potential matarialized yet, and I don't necessarily know that the Spring folks will capitalize on this potential, but I wanted to put list out some thoughts:

 

Phenomenal AJAX Stack: Spring MVC is not siloed, JAX-RS is. JAX-RS stands for JAX (Java API for XML???) RESTful Services. It's focus is on "services", and not on web development. Spring MVC's strength is web development, but is also easily leveraged for Services. Spring MVC has been had 6 years (or so) as a production ready web stack with a steadily increasing following. The JAX-RS implementations don't have anywhere near the same feature set. IMHO, Spring MVC could make a few small changes to have a killer web/AJAX stack.

 

Freedom of Choice: The Spring Framework does integrate with most JAX-RS frameworks. RESTEasy has a deep integration with Spring MVC (thanks to yours truely) as seen in this DZone article on Spring MVC + RESTEasy integration. If you want some combination like Struts2 (or some other MVC alternatives) + REST, then IMHO, Spring MVC is the platform for you already. If you want a consistent HTML/MVC and REST/MVC programming paradigm then @MVC could work phenomenally well for you.

 

JAX-RS/Spring MVC Compatibility Layer: Since JAX-RS and Spring are so similar, a Spring MVC/JAX-RS compatibility layer could add some serious value-add to Spring MVC, by leveraging more advanced uses of Spring MVC by JAX-RS and vice versa. The first thing I would create is adapters for AX-RS's MessageBodyReader/Writers and Spring MVC's equivalents.

 

SOAP/REST Crossover: Spring MVC and Spring-WS are built on similar technologies. There's potential integration between the two Spring technologies. JAX-RS and JAX-WS are siloed and don't seem to have that same potential. How does Spring-WS compare to JAX-WS? That should be an interesting blog post :).

 

Spring Remoting Crossover: Spring Remoting exposes POJO services with some conversion process. You can use a simple POJO service to create remote Java Serialized, AMF (Flex), Hessian or Burlap using some proxying magic. I should be able to expose a POJO service (no annotations) as an XML or JSON endpoint. I should be able to expose AMF (Flex), Java Serialized, Hessian or Burlap through an @MVC application as well. The Spring Remoting package also comes with client-side goodies that could be leveraged by Spring's MVC solution.

 REST Validation: Spring has an excellent validation framework. JAX-RS application's don't do validation all that well. I'd love to see a REST validator from Spring MVC.

Write Once, Configure Anywhere: JAX-RS relies solely on annotations. Spring has a strong XML and annotation configuration offering. Annotations have some great advantages, but have their limits: annotations can only support a single set of static information. There are ways to work around those issues in JAX-RS, but IMHO, the Spring @MVC XML has a lot more substance for complex, run-time, externally configured, meta-data driven systems.

 

Consolidated URI Management: Annotations distribute architectural information in ways that XML doesn't. The Spring XML configuration puts a whole bunch of information in one place, for a high level view of the system. I would love to see a single view of how my system maps URIs to controllers. The Spring MVC backbone can speak Struts2, Spring MVC, Spring @MVC (annotated), Servlets, Wicket, Tapestry and even JAX-RS (through RESTEasy). A tweak or two to the backbone would allow you to view and filter that Controller/Action meta-data. Apache Camel has a nice way of doing this kind of management for endpoints; Spring MVC can do something similar.

Groovier Controllers: I'm pretty disappointed that the spring crew didn't do this earlier. There are so many bite-sized goodies in Grails that can be of immediate value to mainstream Spring development. I personally would rather have a spectrum of Groovy/Spring features rather than a single container approach that Grails takes. Grails is a great as single package, but couldn't some of those goodies make it back to the core?

 

Why doesn't Spring use the JAX-RS annotations?

  • There are nuances that make JAX-RS and Spring MVC incompatible. @Produces in JAX-RS is more of a View decision in Spring MVC. That's because the Spring MVC crew comes from an MVC perspective rather than a service-oriented perspective.
  • The pattern matching in the URITemplates are a bit different between JAX-RS spec (perl regex) and Spring MVC (ant based). This is one of many other small nuances in the processing of the annotations which break compatibility with the JAX-RS standard.
  • There is no JAX-RS counterpart to @SessionAttributes (by design). Spring is meant for web development, and sessions are a fact of life for practical development. If you look at this from a REST purist perspective, sessions are not such a good thing. However, there's no consistent way around it. There are also some philosophical considerations that could make the case for RESTful session management.
  • It's also may a fundamental Spring philosophy issue as well. The JCP process has some great positives. JSR 311 (JAX-RS) had a more open and free discussion than other JSRs. However, there's still something to be said about owning decisions, end-to-end. There are a lot of interesting things that can be done with either a "let's share power" philosophy and with a "I want to make my own decisions" philosophy. Both have their place, and Spring chose their direction a long time ago

Conclusion

Spring maintains its independence from JEE, and therefore has a fair amount of flexibility and potential to make interesting architectural advancements. I don't think the Spring framework found it's stride yet, but knowing the SpringSource guys, I'm expecting big things in 2010.

From http://www.jroller.com/Solomon

Published at DZone with permission of Solomon Duskis, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jilles Van Gurp replied on Thu, 2009/12/10 - 2:16pm

Spring is a nice dependency injection framework but has also got a history of pushing addon framework designs that had to be changed over the course of their history, thus leaving developers with a legacy to maintain. Personally, I have an instinctive reflex of disliking the Spring everything approach. I've been around long enough to distrust silver bullet type solutions, especially the type that will do everything for you. Which is exactly the way the spring coolaid is sold. A few years ago if you'd bought into struts, you'd be fucked now maintaining whatever you developed on top because it is out of fashion and lost momentum. A lot of the Spring stuff falls in the same category. It might be fashionable now but essentially you are just playing the early adopter.

While the more mature bits are pretty cool and usable (e.g. the database stuff) I've also had some encounters with spring MVC and spring webflow where my main conclusion has been that depending on these was a mistake (not my choice btw). Over engineered and absolutely a bitch to maintain while not adding much value over a vanilla servlet/jsp/javascript based approach fashionable just 4-5 years ago. Even for dependency injection, I don't necessarily agree it is the best approach around and it seems these days you are sort of inheriting that because you are depending on something a lot else to begin with. Spring REST framework falls in this category. It doesn't really do anything terribly relevant or better than competing stuff but it is sort of the easiest to start using if you were depending on Spring-* anyway. Don't use it unless you have to.

There are way too much REST frameworks around and way to few good ones. Jax RS is the usual compromise between being useful and being compatible with existing solutions. It's sort of easy to get started with but there are a lot of buts and ifs down the road when you can no longer easily switch framework and are basically stuck with whatever limitations come with your framework of choice. I've had some recent experiences with RestEasy for example that taught me one big important lesson: if the problem is simple, don't use something really complicated to solve it. Basically I'm now in a situation where RestEasy is plain disfunctional and part of the problem and I have a shitload of work ahead of me that basically involves getting rid of it client side in order to stop our websites from going down and doing things the old fashioned way with httpclient instead (which in version 4 is greatly improved). If only RestEasy would always call releaseConnection in a finally block like I would damn well make sure I would do, my life would be a lot simpler right now.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.