2006/10/26, Gopalan Sri:
Jan, you are correct in your assessment that I wish to parameterize my request to go to the next page because my parameters are too complex to represent in a query string. Currently, we are representing our parameter in XML. The reasoning behind this is that we are trying to support an enterprise search operation using a SOAP and REST interfaces. Since we have to encode the request in XML for the SOAP interface, we were hoping to reuse that XML object within our REST based interfaces as well. We are using Atom to capture the results of enterprise search. The problem I encounter arises when we start thinking about the paging of results. For RESTful access to our services, we are trying to use open source/commercial Atom readers that support Open Search. The recommendations laid out by the OpenSearch 1.1 specification (http://www.opensearch.org/Specifications/OpenSearch/1.1#Example_of_OpenSearch_response_elements_in_Atom_1.0) suggest implementing paging with <atom:link/> elements using specific values for @rel (e.g. self, first, previous, next, last). Right now I am trying to figure out how I can still follow their guidance while managing the fact that my parameter cannot easily be encoded as a regular query string. Any thoughts would be appreciated. Thanks for your time.
I think your "search service" should create "temporary resources" and provide URIs for them to use in rel="next" links. A simple implementation is to store an object corresponding to the query parameters within a "Cache" or "Application" server-side object along with a "UniqueID", and then use that id in the URI to identify the query. The object would be removed from the cache/application after some delay of "inactivity". That's pretty easy in ASP.NET developments as the Cache object is provided out-of-the-box; there should be equivalents in the Java world too. -- Thomas Broyer
