GET request and Error Handling with the JpaRepository .findById() method

Question

So I'm going through various resources trying to learn Spring Boot and Rest API and I've encountered the same problem in several different tutorials and textbooks. It seems to stem from the CrudRepository interface and more specifically the JpaRepository.findById() method.

Every tutorial I've read has something to the effect of:

@GetMapping("/{id}")
    public ResponseEntity<UserDTO> getUserById(@PathVariable("id") final Long id){
        UserDTO user = userJpaRepository.findById(id);
        if (user == null) {
            return new ResponseEntity<UserDTO>(
                    new CustomErrorType("User with id " + id + " not found"),
                    HttpStatus.NOT_FOUND);
        }
        return new ResponseEntity<UserDTO>(user, HttpStatus.OK);

However, the UserDTO user = userJpaRepository.findById(id); won't compile.

I figured out if I change it to UserDTO user = userJpaRepository.findById(id).get(); it compiles, runs, and the GET is successful. The problem is if the user ID isn't found in the GET request it doesn't return NULL and I get a 500 internal server error.

The tooltips and suggestions from my IDE corrected the code to

@GetMapping("/{id}")
    public ResponseEntity<UserDTO> getUserById(@PathVariable("id") final Long id){
        Optional<UserDTO> user = userJpaRepository.findById(id);
        if (user == null) {
            return new ResponseEntity<UserDTO>(
                    new CustomErrorType("User with id " + id + " not found"),
                    HttpStatus.NOT_FOUND);
        }
        return new ResponseEntity<UserDTO>(HttpStatus.OK);
    }

Which works just as it should for the GET request and error handling. Why do all the tutorials have it listed the first way? Could someone explain to me what is going on here?

Answer 1

The JpaRepository.getById can retrieve a database record by id. This method is pre-defined, same as the findAll methods. The mentioned method CrudRepository.findById was inherited from ancestor class CrudRepository. It returns a Optional<T> since spring-data migrated to Java 8 (since Spring-Data-Jpa version 2.0).

See more: Spring Data JPA findOne() change to Optional how to use this?

Implementing JpaRepository's find-methods

However, if you implement the JpaRepository and add a new findByName method, this relies on JPA's Query Language (JPQL) and implicitly issues a prepared statement like SELECT * FROM table WHERE name = ?. Here the WHERE clause's predicates like name = ? are extracted and built from method-name, after By.

Rational behind Optional return

The default return of any find method is Optional<T> since Java 8 (which introduced the Optional type). This is because a search may either find some or not. If nothing is found, it is safer to return Optional instead of null or throw an exception. Main benefit and intention behind Optional returns are:

• signal empty = optional results in the method signature (instead of implicit null before)
• force the API user/developer to deal with empty returns
• avoid incidental NullPointerExceptions (NPE)

---

Update to deal with empty results found:

Handling NOT FOUND in REST controllers

A RESTful way of responding in cases of empty or not-found results on CRUD resources is:

• to return HTTP status 404 NOT FOUND with some customized/descriptive error-message.

This "unhappy path" can easily be achieved by throwing Spring's ResponseStatusException like described in Baeldung's REST exception-handling tutorial like this:

@GetMapping("/{id}")
public UserDTO getUserById(@PathVariable("id") final Long id) {
    Optional<UserDTO> user = userJpaRepository.findById(id);
    if (user.isEmpty()) {
        throw new ResponseStatusException(HttpStatus.NOT_FOUND, String.format("User with id %d not found", id));
    }

    return user;
}

What was simplified:

• throwing ResponseStatusException leads to an exceptional return and signals Spring to respond with specified status (404) and body (message).
• controller methods can simply return the type UserDTO (without wrapping in ResponseEntity) because Spring will convert to response-representation
• for @GetMapping the return always gets HttpStatus.OK assigned by default

Further, like Mauricio Gracia Gutierrez tutoring answer explains ideomatic Optional handling, the method-body can be simplified to a one-liner:

return userJpaRepository.findById(id)
       .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND, String.format("User with id %d not found", id)));

Answer 2

Some hints on how to use Optional with Optional<T> findById(ID id).

Generally, as you look for an entity by id, you want to return it or make a particular processing if that is not retrieved.

Here are three classical usage examples.

1. Suppose that if the entity is found you want to get it otherwise you want to get a default value.

You could write :

Foo foo = repository.findById(id)
                    .orElse(new Foo());

or get a null default value if it makes sense (same behavior as before the API change) :

Foo foo = repository.findById(id)
                    .orElse(null);

2. Suppose that if the entity is found you want to return it, else you want to throw an exception.

You could write :

return repository.findById(id)
        .orElseThrow(() -> new EntityNotFoundException(id));

3. Suppose you want to apply a different processing according to if the entity is found or not (without necessarily throwing an exception).

You could write :

Optional<Foo> fooOptional = fooRepository.findById(id);
if (fooOptional.isPresent()) {
    Foo foo = fooOptional.get();
    // processing with foo ...
} else {
    // alternative processing....
}

Exctract taken from Spring Data JPA findOne() change to Optional how to use this?