You can notice the use of Pageable arguments in the methods of our repository interfaces. For example below is the IndexRepositoryJpa repository:

public interface IndexRepositoryJpa extends JpaRepository<Index, 
  String>{
  List<Index> findByMarket(Market market);
  Page<Index> findByMarket(Market market, Pageable pageable);
  List<Index> findAll();
  Page<Index> findAll(Pageable pageable);
  Index findByCode(MarketCode code);
}

Spring Data recognizes the org.springframework.data.domain.Pageable Type as the method argument. It also recognizes the org.springframework.data.domain.Sort Type when a full Pageable instance is not necessary. It applies pagination and sorting to our queries dynamically.

You can see more examples here (taken from the Spring reference document):

Page<User> findByLastname(String lastname, Pageable pageable);
Slice<User> findByLastname(String lastname, Pageable pageable);
List<User> findByLastname(String lastname, Sort sort);
List<User> findByLastname(String lastname, Pageable pageable);

From these extra examples, you can see that Spring Data can return a Page (org.springframework.data.domain.Page), a Slice (org.springframework.data.domain.Slice) or simply a List.

But here is the amazing part: a Page object contains everything we need to build powerful pagination tools at the front end! Earlier, we saw the json response provided with one Page of elements.

With With the following request: http://localhost:8080/api/indices/US.json?size=2&page=0&sort=dailyLatestValue,asc, we have asked for the first page and received a Page object telling us whether or not this page is the first or the last one (firstPage: true/false, lastPage: true/false), the number of elements within the page (numberOfElements: 2), the total number of pages, and the total number of elements (totalPages: 2, totalElements: 3).

A Slice object is a super interface of Page, which does not carry the counts for numberOfElements and totalElements.

If a repository does not already extend JpaRepository<T,ID>, we can make it extend PagingAndSortingRepository<T,ID>, which is an extension of CrudRepository<T,ID>. It will provide extra methods to retrieve Entities using the pagination and sorting abstraction. These methods are:

  Iterable<T> findAll(Sort sort);
  Page<T> findAll(Pageable pageable);

As introduced earlier, we have added the org.springframework.data.web.PageableHandlerMethodArgumentResolver bean to our RequestMappingHandlerAdapter as a customArgumentResolver. Doing so has allowed us to rely on the Spring data binding to transparently prepopulate a Pageable instance available as a method handler argument (highlighted in bold in the 1st step of this recipe).

Here is some more information about the request parameters we can use for the binding:

As implemented in our first step, default values can be customized in cases where specific parameters are missing. This is achieved with the @PageableDefault annotation:

@PageableDefault(
size=10, page=0, sort={"dailyLatestValue"}, direction=Direction.DESC
)

If for some reason we don't make use of PageableHandlerMethodArgumentResolver, we can still catch our own request parameters (for pagination) and build a PageRequest instance from them (for example, org.springframework.data.domain.PageRequest is a Pageable implementation).

The Spring Data reference document tells us that JPA 2 has introduced a criteria API that can be used to build queries programmatically. When writing criteria, we actually define the where clause of a query for a domain class.

The Spring Data JPA takes the concept of specification from Eric Evans's book Domain Driven Design, following the same semantics and providing an API to define such specifications using the JPA criteria API.

To support specifications, we can extend our repository interface with the JpaSpecificationExecutor interface, as we did in our ProductRepository interface:

@Repository
public interface ProductRepository<T extends Product> extends JpaRepository<T, String>, JpaSpecificationExecutor<T> {
  Page<T> findByMarket(Market marketEntity, Pageable pageable);
  Page<T> findByNameStartingWith(String param, Pageable pageable);
  Page<T> findByNameStartingWith(String param, Specification<T> spec, Pageable pageable);
}

In our example, the findByNameStartingWith method retrieves all the products of a specific Type (StockProduct) that have a name starting with the param argument and that match the spec specification.

As we said earlier, this CustomArgumentResolver is not bound to an official Spring project (yet). Its use can fit some use cases such as local search engines to complement Spring Data dynamic queries, pagination, and sorting features.

In the same way we build a Pageable instance from specific parameters, this argument resolver also allows us to transparently build a Specification instance from specific parameters.

It uses @Spec annotations to define where clauses such as like, equal, likeIgnoreCase, in, and so on. These @Spec annotations can then be combined with each other to form groups of AND and OR clauses with the help of @And and @Or annotations. A perfect use case is to develop our search features as a complement to the pagination and sorting function.

You should read the following article which is an introduction to the project. This article is entitled "an alternative API for filtering data with Spring MVC & Spring Data JPA":

http://blog.kaczmarzyk.net/2014/03/23/alternative-api-for-filtering-data-with-spring-mvc-and-spring-data

Also, find with the following address the project’s repository and its documentation:

https://github.com/tkaczmarzyk/specification-arg-resolver