Exception handling is one of the important parts of developing web services. When something goes wrong, we would want to return a good description of what went wrong to the service consumer. You would not want the service to crash without returning anything useful to the service consumer.

Spring Boot provides good default exception handling. We will start with looking at the default exception handling features provided by Spring Boot before moving on to customizing them.

Spring Boot Default Exception Handling

To understand the default exception handling provided by Spring Boot, let's start with firing a request to a nonexistent URL.

Non-Existent Resource

Let's send a GET request to http://localhost:8080/non-existing-resource using a header (Content-Type:application/json).

The following screenshot shows the response when we execute the request:

The response is as shown in the following code snippet:

    {
      "timestamp": 1484027734491,
      "status": 404,
      "error": "Not...

HATEOAS (Hypermedia as the Engine of Application State) is one of the constraints of the REST application architecture.

Let's consider a situation where a service consumer is consuming numerous services from a service provider. The easiest way to develop this kind of system is to have the service consumer store the individual resource URIs of every resource they need from the service provider. However, this would create tight coupling between the service provider and the service consumer. Whenever any of the resource URIs change on the service provider, the service consumer needs to be updated.

Consider a; typical web application. Let's say I navigate to my bank account details page. Almost all banking websites would show links to all the transactions that are possible on my bank account on the screen so that I can easily navigate using the link.

What if we can bring a; similar concept to RESTful services so that a service returns not only the data about the requested resource, but...

A good service always validates data before processing it. In this section, we will look at the Bean Validation API and use its reference implementation to implement validation in our services.

The Bean Validation API provides a number of annotations that can be used to validate beans. The JSR 349 specification defines Bean Validation API 1.1. Hibernate-validator is the reference implementation; both are already defined as dependencies in the spring-boot-web-starter project:

We will create a simple validation for the createTodo service method.

Creating validations involves two steps:

    @RequestMapping(method = RequestMethod.POST, 
    path = "/users/{name}/todos")
    ResponseEntity<?>...

Before a service provider can consume a service, they need a service contract. A service contract defines all the; details about a service:

There are multiple options to define a service contract for RESTful services. The most popular one in the last couple of years is Swagger. Swagger is gaining a lot of ground, with support from major vendors in the last couple of years. In this section, we will generate Swagger documentation for our services.

The following quote from the Swagger website (http://swagger.io) defines the purpose of the Swagger specification:

Swagger specification creates the RESTful contract for your API, detailing all of its resources and operations in a human and machine readable format for easy development, discovery, and integration.

All the services we have created up until now are unsecured. A consumer does not need to provide any credentials to access these services. However, all services in the real world are usually secured.

In this section, we will discuss two ways of authenticating REST services:

We will implement these two types of authentication with Spring Security.

Spring Boot provides a starter for Spring Security using spring-boot-starter-security. We will start with adding Spring Security starter to our pom.xml file.

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-security</artifactId>
    </dependency>

Internationalization (i18n) is the process of developing applications and services so that they can be customized for different languages and cultures across the world. It is also called localization. The goal of internationalization or localization is to build applications that can offer content in multiple languages and formats.

Spring Boot has built-in support for internationalization.

Let's build a simple service to understand how we can build internationalization in our APIs.

We would need to add a LocaleResolver and a message source to our Spring Boot application. The following code snippet should be included in Application.java:

    @Bean
    public LocaleResolver localeResolver() {
      SessionLocaleResolver sessionLocaleResolver = 
      new SessionLocaleResolver();
      sessionLocaleResolver.setDefaultLocale(Locale.US);
      return sessionLocaleResolver;
    }

   @Bean
   public ResourceBundleMessageSource messageSource() {
     ResourceBundleMessageSource...

Caching data from services plays a crucial role in improving the performance and scalability of applications. In this section, we will look at the implementation options that Spring Boot provides.

Spring provides a caching abstraction based on annotations. We will start with using Spring caching annotations. Later, we will introduce JSR-107 caching annotations and compare them with Spring abstractions.

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-cache</artifactId>
    </dependency>