Pagination in a REST web app

Question

Usually, a user makes a search, get a hitlist, and can then browse it. The hitlist is an intermediate result that remains consistent throughout the browsing and is typically stored in session state. E.g. if new items are added concurrently by some other, they would appear only in a subsequent search.

In a REST application, I can't have this intermediate result easily -- neither does it belong to the client, nor the model. I have read Pagination in a REST web app, but am not completely clear with the answer. The solution there seems to assume that the model is not updated while the user browses the results.

We can of course imagine the world (the model) as series of immutable snapshot. By providing a timestamp (or a global version number), we then get a consistent view of the model at that time, which solves the problem from a conceptual point of view. It does however imply full versioning of the model. (I'm also wondering if there is a connection to draw with functional programming)

How should I deal with this issue?

Note: I'm asking because I plan to use the play framework, which has no notion of HTTP state or session at all; it's pure restful.

Answer 1

I'm kind of lost about what your context is, but if I have to provide a short answer, it is that search results should be part of the model. I assume you have a searchable model. What you do is index the parts you need to search and store the index info (making it part of the model, too). When you execute a search, you query the index and display results. Performing the search a second time would not contain newly added items, unless the index is regenerated.

This removes the need to use any session state and keeps it restful, as the indexing is just another operation performed on a resource. Is this what you need?

Answer 2

Hi

After you've got query result on the first search, You can save the result in a cache. For one server it can be ehcache (supported in play) or memcached (also supported by play) for a cluster environment. You can save the result by a static name + session id. So you only need session id for each request, it's saved in the client cookie and available in your play app. You can use cached data for browsing pages. I'm also recommending ElasticSearch.

EDIT: A better way is you can use play-search http://github.com/jfp/play-search, Sample:

    Query q = Search.search("object:dogs", Folder.class);
q.orderBy("object")
    .page(2,5)
    .reverse();

PS: Your decision with Play is perfect. I'm a professional .net developer and I can say the only (optimal) web framework in the world that can race with asp.net mvc 2 is Play framework. Grails is buggy, Django/Python, Yii/Php, Rails all are slow, not type safe and far from jvm/clr frameworks. wicket, tapestry, struts, jsf, spring mvc all are verbose and useless. spring roo is only a template generator. Asp.net mvc surpassed asp.net and became #1 development platform for .net, but sun worked for an old asp.net clone with jsf for next gen, big mistake. The only hope for java is play framework in my opinion. With scala module, it's perfect...