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_o
f_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
|