RE: Adding POST capability to atom:link

[Gopalan Sri]

Thank you all for your quick response.  I apologize for the weak description of my problem. 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. Sri  From: Jan Algermissen [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 3:05 PM To: Gopalan Sri Cc: atom-syntax@imc.org Subject: Re: Adding POST capability to atom:link On 26.10.2006, at 18:24, Gopalan Sri wrote: to support something like this: <link rel="next" href=""http://example.com">http://example.com/" type="application/atom+xml" action="">     <parameter name="q">         <xxx:Payload/>     </parameter>     <parameter name="blah" value="blah"/> </link> If I understand this correctly, you intent to parameterize the request to go to the next page; since your parameters seem to be too complex to but them into the query string, you thought about using POST - yes? If so, this is bad practice anyhow, since you loose all the benefits of GET. Jan