Hi Nishant,
I did this a few months ago and did not find any "official" recipes for
pagination, so I created my own. Note, if you want to use HATEOAS and
links, my example does not cover that but there is a Jersey module for it.
Here's a GIST of my example with some of the proprietary stuff scrubbed out:
https://gist.github.com/bowenwr/57e39ea14f7eede0d804
In my example, I use HTTP headers for pagination and other options because
to me it *feels *more "RESTful" but if your API is public facing, you might
want to consider query parameters so that people can try out your API via a
browser URI.
Here is a general walk-through of what I did:
1. Create a Pagination object to hold pagination info. It's also
responsible for being able to parse the info from a HttpServletRequest,
which in my case means headers but you could easily change to query
parameters.
2. I use a generic RequestOptions to wrap my Pagination object because I
have some other things the client can set such as a flag for recursion in
some requests.
3. I have a PaginationException and PaginationExceptionMapper for
processing pagination exceptions, which really just turns it into
a HTTP 400 error in case the client supplies something bad like letters
instead of numbers. These need to be registered in your ResourceConfig.
4. I created a RequestOptionsValueFactoryProvider and registered it via
InjectionBinder with ResourceConfig, which basically allows me to
inject RequestOptions
into my resource classes to easily make it available for any methods
that need to access pagination info. Methods that POST/PUT or GET single
entities can just ignore it. You'll see this injection in my SampleResource
class.
5. Finally, there is a response filter RequestOptionsResponseFilter that
will take info put into the request context (via a HelperResource class
I created with static methods to reduce repeated code in my
SampleResource) during the SampleResource processing and pass it along
to the client in the form of headers. This tells the client how many
total records were available, plus what offset/limit were applied. The
SampleResource will also look for a HEAD HTTP method and will not
perform the retrieval of the actual results in this case, but still return
the pagination info.
Hope that helps. I'd be interested in hearing of any other approaches
people have used.
- William
On Thu, Sep 4, 2014 at 4:01 PM, Nishant Chandra <nishant_at_ncredibles.com>
wrote:
> Hi,
>
> I have been trying to find a good way to implement pagination for an API
> and came across few options e.g. use headers or query params.
>
> Has anyone tried this with Jersey (in combination with Spring JPA) ? Any
> pointers to a sample code will be helpful.
>
> Thanks,
> Nishant
>