This is the seventh of a series of articles about setting up a secure RESTful Web Service using Spring 3.1 and Spring Security 3.1 with Java based configuration. This article will focus on the implementation of pagination in a RESTful web service.
The REST with Spring series:
- Part 1 – Bootstrapping a web application with Spring 3.1 and Java based Configuration
- Part 2 – Building a RESTful Web Service with Spring 3.1 and Java based Configuration
- Part 3 – Securing a RESTful Web Service with Spring Security 3.1
- Part 4 – RESTful Web Service Discoverability
- Part 5 – REST Service Discoverability with Spring
- Part 6 – Basic and Digest authentication for a RESTful Service with Spring Security 3.1
Page as resource vs Page as representation
The first question when designing pagination in the context of a RESTful architecture is whether to consider the page an actual resource or just a representation of resources. Treating the page itself as a resource introduces a host of problems such as no longer being able to uniquely identify resources between calls. This, coupled with the fact that outside the RESTful context, the page cannot be considered a proper entity, but a holder that is constructed when needed makes the choice straightforward: the page is part of the representation.
The next question in the pagination design in the context of REST is where to include the paging information:
- in the URI path: /foo/page/1
- the URI query: /foo?page=1
Keeping in mind that a page is not a resource, encoding the page information in the URI is no longer an option.
Page information in the URI query
Encoding paging information in the URI query is the standard way to solve this issue in a RESTful service. This approach does however have one downside – it cuts into the query space for actual queries: