Thanks William. Your sample code was very useful.
I have used Declarative Linking module and it works great. However, I am
unable to figure out 1 thing:
1. Say OrderResource has 3 API for getting orders - new, cancelled and
returned. The response is paginated.
2. The response object "Order" is annotated with @InjectLinks. Value for
"method" has to be provided to correctly construct the URI. So if response
object is shared by multiple APIs, how do I bind the "method" to the right
method in Resource?
On Sat, Sep 6, 2014 at 12:31 AM, William Bowen <williamrbowen_at_gmail.com>
wrote:
> 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
>>
>
>
--
Thanks,
Nishant Chandra