REST services are one of the most often encountered ways to implement communication between two apps. REST offers access to functionality the server exposes through endpoints a client can call.

You use REST services to establish the communication between a client and a server in a web app. But you can also use REST services to develop the communication between a mobile app and a backend or even two backend services:

Because in many Spring apps today you have chances to encounter and work on REST services, I consider this subject a must-learn for every Spring developer.

Using REST services to exchange data between apps

REST endpoints are simply a way for implementing communication between two apps. REST endpoints are as simple as implementing a controller action mapped to an HTTP method and a path. An app calls this controller action through HTTP. Because it’s how an app exposes a service through a web protocol, we call this endpoint a web service.

In the end, in Spring a REST endpoint is still a controller action mapped to an HTTP method and path. Spring uses the same mechanism you learned for web apps for exposing REST endpoints. The only difference is that for REST services we’ll tell the Spring MVC dispatcher servlet not to look for a view. In the Spring MVC diagram you learned in chapter 6, the view resolver disappears. The server sends back, in the HTTP response to the client, directly what the controller’s action returns.

The changes in the Spring MVC flow:

You’ll find REST services are comfortable to use. Their simplicity is one reason they’re so often used today, and Spring makes their implementation straightforward. But before starting with our first example, I’d like to make you aware of some communication issues the REST endpoint might bring:

• If the controller’s action takes a long time to complete, the HTTP call to the endpoint might time out and break the communication.
• Sending a large quantity of data in one call (through the HTTP request) might cause the call to time out and break the communication. Sending more than a few megabytes through a REST call usually isn’t the right choice.
• Too many concurrent calls on an endpoint exposed by a backend component might put too much pressure on the app and cause it to fail.
• The network supports the HTTP calls, and the network is never 100% reliable. There’s always a chance a REST endpoint call might fail because of the network.

Implementing a REST endpoint

I’ll build my example over what we already discussed in chapters 6 and 7, and you’ll learn how to transform a simple web controller into a REST controller to implement REST web services.

The following snippet shows you a controller class that implements a simple action. As you learned from chapter 7, we annotate the controller class with the @Controller stereotype annotation. This way, an instance of the class becomes a bean in the Spring context, and Spring MVC knows this is a controller that maps its methods to specific HTTP paths. Also, we used the @GetMapping annotation to specify the action path and HTTP method. The only new thing you find in this listing is the use of the @ResponseBody annotation. The @ResponseBody annotation tells the dispatcher servlet that the controller’s action doesn’t return a view name but the data sent directly in the HTTP response:

@Controller                     ❶
public class HelloController {

  @GetMapping("/hello")         ❷
  @ResponseBody                 ❸
  public String hello() {
    return "Hello!";
  }
}

❶ We use the @Controller annotation to mark the class as a Spring MVC controller