Spring REST Framework Potential
Spring REST Framework Potential
Join the DZone community and get the full member experience.Join For Free
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
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.
Opinions expressed by DZone contributors are their own.