With a HandlerInterceptor
you can:
- Change the
HttpServletResponse
in preHandle
method
- Apply filters based on
handler
object. For example, you can apply some filters based on presence of some annotations on HandlerMethod
- Prohibit the execution of the handler by returning
false
in preHandle
method.
HandlerInterceptor
can be used for a large field of preprocessing aspects, e.g. for authorization checks, or common handler behavior like locale, theme changes or adding Cache-Control
headers. Its main purpose is to allow for factoring out repetitive handler code.
One of the canonical use cases of WebRequestInterceptor
is preparing context resources (such as a Hibernate Session
) and expose them as request attributes or as thread-local objects. Also, you can modify those context resources after successful handler execution (for example, flushing a Hibernate Session
). For example, OpenEntityManagerInViewInterceptor
binds a JPA EntityManager
to the thread for the entire processing of the request.
Although seeing Spring API I can guess that WebRequestInterceptor can
not commit response while HandlerInterceptor can do that. Please
correct me here if I am wrong.
WebRequestInterceptor
interface is deliberately minimalistic to keep the dependencies of generic request interceptors as minimal as feasible. If you need to change the response, you should use HandlerIntercepter
or Filter
s.