Thread: [Resteasy-developers] Integrating RESTEasy & Spring MVC - Part I

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I'm thinking through what's needed in order to integrate REST Easy and
Spring MVC.  Before I explain the integration, I think I need to explain how
Spring MVC work.  This turned into a pretty lengthy article, but I think
that the goals of the integration are pretty interesting...  Basically, I
think this could extend both the abilities of Spring MVC and JAX-RS's
capabilities.  If done properly, the integration will allow JAX-RS to act as
an MVC controller or work along side other complementary MVC technologies.
When it comes to the implementation, I'll be pretty careful to separate out
the Spring MVC specific code and the code required to make RESTEay IoC and
MVC accessible.  James Strachan is taking a look at a Guice/JAX-RS
integration, and I'll keep his ideas in mind as well:
http://macstrac.blogspot.com/2008/10/adding-support-for-postconstruct.html

*MVC*

You probably know what MVC is, but I'll rehash it anyway.

Model - Sevice Layer and below, it also includes the Domain Layer.
Controller - an object/method that's responsible for the logic that the UI
needs - validation, binding, error handling, relaying messages between the
Model and View
View - show the data

Web MVC has the following specifics:
- URL determines Controller
- The Controller handles setting HTTP headers (cookies, caching & etc)
- Controller does it's work and passes back data and some way to determine a
View
  -- the view determination can be based a string representing a logical
name (Struts and Spring MVC do this)
  -- the view can be determined based on the data (similar to JAX-RS or
DWR).

Web MVC tends to have a DispatchingServlet that performs the handoff to the
Controller.  There needs to be some storage and management of URLMappings,
Controllers and Views.  Each MVC has their own proprietary management
system, but can generally work with a generic IoC Container.

  (One of the benefits of using IoC Containers is that the Model and
Controllers are managed by the same construct, so you don't have to perform
service lookups.)

Taking a step back, JAX-RS is already a Web MVC implementation!

*Spring MVC
*
Spring MVC has a few decoupled parts to it :

1) A couple APIs for creating Controllers: the old way uses a class
hierarchy, and the new way uses annotations that are similar to JAX-RS's
annotations.

2) A mechanism for rendering Views: you can choose from a plethora of view
technologies: JSP/JSTL, JSF, Tiles, Velocity, FreeMarker and XSLT.
Theoretically, you can create a View that knows how to transform objects via
JAXB; there are JSon-Lib and Jettison based Views.

3) An object that encapsulates both the data and the logical view:
ModelAndView.  Model is a Map of data, and view is the logical name of the
View, or the View object itself.

4) A mechanism for URL Mapping - HandlerMapping: given a URL, it helps you
find a Spring managed bean.  You have different strategies you can use, or
you can build your own:
  A) Use the URLS configured in @Controller objects,
  B) Map a URL to the name the controller (/customer maps to
CustomerController)
  C) Explicitely configure URL regex to controller via key/value pairs
  D) Roll out your own custom mapping (for example, you can lookup a
"controller"/ResourceInvoker in the RESTEasy Dispatcher)

Using approach C has the side affect of allowing you to add on functionality
via explicitly configuring Interceptors, although I believe that the other
implementations can work with interceptors

5) A mechanism for handling the bean found by the HandlerMapping -
HandlerAdapter: the bean found in #4 could be a traditional Spring MVC
controller, an annotated Spring MVC controller, a Servlet, a Struts Action
or a JAX-RS resource.  HandlerAdapters are adapters that know what kinds of
beans they handle, and how to pass the HTTP request/response to those
beans.  Each Handler adapter returns a ModelAndView which is then rendered
by #2

6) A mechanism for binding web data (specifically incoming request/form
parameters) into a DTO.  Basically, it has a convention that maps request
parameters to potentially nested values.  For example, foo.bar.baz would
translate into myDto.getFoo().getBar().setBaz().  It also allows for some
binding from String to Object conversion similar to @Providers.  In the new
@Controller mechansim, you can list out the parameters in the method,
similar to JAX-RS, or you can have a DTO object that encapsulate those
parameters

7) Validation

8) Objects from the Session

*What JAX-RS has the Spring MVC doesn't*

1) JAX-RS has a much more robust set of web annotations (CookieParam,
MatrixParam, ProduceMime, ConsumeMime and etc)

2) Deep JAXB integration.  It's possible to use JAXB (or
Jettison/XStream/Jibx) to render results in Spring, but you'd have to write
and integrate it yourself.  You can't currently bind a JSon POST to a POJO
using Spring MVC.

3) Different REST Representation depending on configuration and request
headers.

I'm sure I'm missing some other JAX-RS benefits, but these are the ones that
stand out off the top of my head.

*Goals of JAX-RS and Spring MVC*

1) JAX-RS and other "controllers" working side by side.  Different
controller implementation APIs have different strengths and weaknesses.
Currently, JAX-RS doesn't work with HTTPSession, but Spring MVC does.  Sure
it would cause a bit of a management headache to have a few controller
development models, but it's a headache that exists right now for people
that need both HTML and JSon/XML websites.  I've used Spring MVC for HTML
representation, and DWR for Data/JSon transfers.  Theoretically, you can do
this right now, by deploying the RESTEasy servlet + the Spring MVC Servlet,
but a deeper integration would expose more functionality.

2) JAX-RS as a Controller:

  A) Validation integration into JAX-RS, with a common way to expose
validation errors...  I'm not quite sure how this would work, and there may
be better integrations with the Validation JSR, but this would be possible.

  B) Binding a set of parameters as into a JAXB Object/POJO?  Basically,
Spring MVC provides the means to have an object that encapsulates a set of
request parameters.  Is there a way to use JAX-RS/RESTEasy that way?

3) Providers as Views: Using the JAX-RS Producers to implement Spring
Views... This would allow Spring Controllers to render results with the
RESTEasy Producer infrastructure.

4) JAX RS Resources with complex HTML Views:  Clever integration would allow
results from a JAX-RS Resource to be rendered with a complex HTML
representation provided by the View technologies that Spring MV supports:
jsp/jsf/freemarker/velocity Views can also be used for
@Produces("text/html").   This could also be used for
Produces("application/xml") where you don't necessarily want to use an
object based binding technology.

*Conclusion*

I hope that there's enough here to convince you that it's a good idea to
explore the possibilities of integration JAX-RS with Spring MVC.  I'm going
to send a follow up that describes what I think needs to be done in order to
accomplish this integration.

-Solomon Duskis

Thread: [Resteasy-developers] Integrating RESTEasy & Spring MVC - Part I

resteasy-developers