While the command-line applications do have their place and use, most of today's application development is centered around web, REST, and data services. Let's start with enhancing our BookPub application by providing it with a web-based API in order to get access to the book catalogs.

We will start where we left off in the previous chapter, so there should already be an application skeleton with the entity objects and a repository service defined and a connection to the database configured.

1. The very first thing that we will need to do is add a new dependency to build.gradle with the spring-boot-starter-web starter to get us all the necessary libraries for web...

In the previous example, we fronted our BookRepository interface 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 expose it to the web.

We will continue from where we finished in the previous recipe, and so the entity models and the BookRepository interface 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. 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 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...

While servlet filters are a part of the Servlet API and have 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. 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 using filters, Spring MVC comes with a number of premade HandlerInterceptors. The...

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 so as to translate our entity beans into a JSON representation written to HTTP response using the Jackson library. 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...

In the previous example, we learned how to configure converters for an HTTP request and response data. There are other kinds of conversions that take place, especially in regards to dynamically converting parameters to various objects, such as Strings to Date or an Integer.

When we declare a mapping method in a controller, Spring allows us to freely define the method signature with the exact object types that we require. The way in which this is achieved is via the use of the PropertyEditor implementations. PropertyEditor is a default concept defined as part of the JDK and designed to allow the transformation of a textual value to a given type. It was initially intended to be used to build Java Swing / Abstract Window Toolkit (AWT) GUI and later proved to be a good fit for Spring's need to convert web parameters to method argument types...

Mostly because of its statefulness and lack of thread safety, since version 3, Spring has added a Formatter interface as a replacement for PropertyEditor. The formatters are intended to provide a similar functionality but in a completely thread-safe manner and focusing on a very specific task of parsing a String in an object type and converting an object to its String representation.

Let's suppose that for our application, we would like to have a formatter that would take the ISBN number of a book in a String form and convert it to a book entity object. This way, we can define the controller request methods with a Book argument when the request URL signature only contains an ISBN number or a database ID.