@FunctionalInterface
public interface Controller
HttpServletRequest and HttpServletResponse
 instances just like a HttpServlet but is able to
 participate in an MVC workflow. Controllers are comparable to the
 notion of a Struts Action.
 Any implementation of the Controller interface should be a reusable, thread-safe class, capable of handling multiple HTTP requests throughout the lifecycle of an application. To be able to configure a Controller easily, Controller implementations are encouraged to be (and usually are) JavaBeans.
After a DispatcherServlet has received a request and has
 done its work to resolve locales, themes, and suchlike, it then tries
 to resolve a Controller, using a
 HandlerMapping.
 When a Controller has been found to handle the request, the
 handleRequest
 method of the located Controller will be invoked; the located Controller
 is then responsible for handling the actual request and — if applicable
 — returning an appropriate
 ModelAndView.
 So actually, this method is the main entry point for the
 DispatcherServlet
 which delegates requests to controllers.
 
So basically any direct implementation of the Controller interface
 just handles HttpServletRequests and should return a ModelAndView, to be further
 interpreted by the DispatcherServlet. Any additional functionality such as
 optional validation, form handling, etc. should be obtained through extending
 AbstractController
 or one of its subclasses.
 
The Controller interface is explicitly designed to operate on HttpServletRequest and HttpServletResponse objects, just like an HttpServlet. It does not aim to decouple itself from the Servlet API, in contrast to, for example, WebWork, JSF or Tapestry. Instead, the full power of the Servlet API is available, allowing Controllers to be general-purpose: a Controller is able to not only handle web user interface requests but also to process remoting protocols or to generate reports on demand.
Controllers can easily be tested by passing in mock objects for the
 HttpServletRequest and HttpServletResponse objects as parameters to the
 handleRequest
 method. As a convenience, Spring ships with a set of Servlet API mocks
 that are suitable for testing any kind of web components, but are particularly
 suitable for testing Spring web controllers. In contrast to a Struts Action,
 there is no need to mock the ActionServlet or any other infrastructure;
 mocking HttpServletRequest and HttpServletResponse is sufficient.
 
If Controllers need to be aware of specific environment references, they can choose to implement specific awareness interfaces, just like any other bean in a Spring (web) application context can do, for example:
org.springframework.context.ApplicationContextAwareorg.springframework.context.ResourceLoaderAwareorg.springframework.web.context.ServletContextAwareSuch environment references can easily be passed in testing environments, through the corresponding setters defined in the respective awareness interfaces. In general, it is recommended to keep the dependencies as minimal as possible: for example, if all you need is resource loading, implement ResourceLoaderAware only. Alternatively, derive from the WebApplicationObjectSupport base class, which gives you all those references through convenient accessors but requires an ApplicationContext reference on initialization.
Controllers can optionally implement the LastModified interface.
LastModified, 
SimpleControllerHandlerAdapter, 
AbstractController, 
MockHttpServletRequest, 
MockHttpServletResponse, 
ApplicationContextAware, 
ResourceLoaderAware, 
ServletContextAware, 
WebApplicationObjectSupport| Modifier and Type | Method and Description | 
|---|---|
| ModelAndView | handleRequest(HttpServletRequest request,
             HttpServletResponse response)Process the request and return a ModelAndView object which the DispatcherServlet
 will render. | 
@Nullable ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws java.lang.Exception
null return value is not an error: it indicates that
 this object completed request processing itself and that there is therefore no
 ModelAndView to render.request - current HTTP requestresponse - current HTTP responsenull if handled directlyjava.lang.Exception - in case of errors