In the previous example, we fronted our BookRepository with a REST controller in order to expose the data behind it via a web RESTful API. While this is definitely a quick and easy way to make the data accessible, it does require us to manually create a controller and define the mappings for all the desired operations. To minimize the boilerplate code, Spring provides us with a more convenient way: spring-boot-starter-data-rest. This allows us to simply add an annotation to the repository interface and Spring will do the rest to to expose it to the web.

We will continue from the place where we had finished in the previous recipe, and so the entity models and the BookRepository should already exist.

In a real-world web application, we almost always find a need to add facades or wrappers to service requests; to log them, filter out bad characters for XSS, perform authentication, and so on and so forth. Out of the box, Spring Boot automatically adds OrderedCharacterEncodingFilter and HiddenHttpMethodFilter, but we can always add more. Let's see how Spring Boot helps us achieve this task.

Among the various assortments of Spring Boot, Spring Web, Spring MVC, and others, there is already a vast variety of different servlet filters that are available and all we have to do is to define them as beans in the configuration. Let's say that our application will be running behind a load balancer proxy and we would like to translate the real request IP that is used by the users instead of the IP from the proxy when our application instance receives the request. Luckily, Tomcat 8 already provides us with an implementation: RemoteIpFilter. All we will need...

While Servlet Filters are a part of the Servlet API and have really nothing to do with Spring—besides being automatically added in the filter chain—Spring MVC provides us with another way of wrapping web requests: HandlerInterceptor. According to the documentation, HandlerInterceptor is just like a Filter; but instead of wrapping a request in a nested chain, an interceptor gives us cutaway points at different phases, such as before the request gets handled, after the request has been processed, before the view has been rendered, and at the very end, after the request has been fully completed. It does not let us change anything about the request but it does let us stop the execution by throwing an exception or returning false if the interceptor logic determines so.

Similar to the case with Filters, Spring MVC comes with a number of premade HandlerInterceptors. The commonly used ones are LocaleChangeInterceptor and ThemeChangeInterceptor; but there...

While we were building our RESTful web data service, we defined the controllers, repositories, and put some annotations on them; but nowhere did we do any kind of object translation from the java entity beans to the HTTP data stream output. However, behind the scenes, Spring Boot automatically configured HttpMessageConverters to translate our entity beans objects into a JSON representation using Jackson library, writing the resulting JSON data to an HTTP response output stream. When multiple converters are available, the most applicable one gets selected based on the message object class and the requested content type.

The purpose of HttpMessageConverters is to translate various object types into their corresponding HTTP output formats. A converter can either support a range of multiple data types or multiple output formats, or a combination of both. For example, MappingJackson2HttpMessageConverter can translate any Java Object into application/json...