Subject: Adding POST capability to atom:link

From: "Gopalan Sri" <[email-masked]>
Date: Thu, 26 Oct 2006 12:24:09 -0400

Hello,

I am trying to use opensearch to do some paging of my search results and
I have a question regard adding POST capabilities to the atom:link
construct.

The information I want to pass back to the server is complex in nature
and makes sense to capture in XML.  My question is whether or not there
are any thoughts or plans to extend the atom:link contruct to support
something like this:

<link rel="next" href="http://example.com/" type="application/atom+xml"
action="POST">
    <parameter name="q">
        <xxx:Payload/>
    </parameter>
    <parameter name="blah" value="blah"/>
</link>

Thanks.
Sri Gopalan
Booz Allen Hamilton
Office: Allen 147
Tel: 703.377.1404
Mobile: 703.395.4057

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 26 Oct 2006 18:52:04 +0200

>     <parameter name="blah" value="blah"/>

I hope such a thing won't ever exist !!!

-- 
Thomas Broyer

---

From: James M Snell <[email-masked]>
Date: Thu, 26 Oct 2006 10:23:09 -0700

+1. This would not, IMHO, be a good thing for Atom.  Feel free to define
an extension if you think it would be good.  Implementations that find
it useful could choose to support it but I doubt you'll find many.

- James

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Oct 2006 19:46:35 +0200

Gopalan,

> I have a question regard adding POST capabilities to the atom:link

atom link is not the appropriate place to do something like this. The  
issue of
the server telling the client what resources implement POST is  
addressed by
the Atom Publishing Protocol[1] in the form of collections. If you  
need to
communicate more details, you'd have to use an extension such as
atompub-features[2] (its intention though is to enable services to  
declare
behavioural aspects of a collection and not to declare an input form but
atompub-feature's controls can be used much like a forms language).

HTH,
Jan

[1] http://www.ietf.org/internet-drafts/draft-ietf-atompub- 
protocol-11.txt
[2] http://www.ietf.org/internet-drafts/draft-snell-atompub- 
feature-01.txt

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 26 Oct 2006 19:58:45 +0200

* Gopalan Sri <[email-masked]> [2006-10-26 18:50]:
> The information I want to pass back to the server is complex in
> nature and makes sense to capture in XML. My question is
> whether or not there are any thoughts or plans to extend the
> atom:link contruct to support something like this:

My answer is that the element is called `link` and you’re asking
for something other than a link.

I certainly hope that clients will never ever be expected to
issue anything other than GET in order to dereference a link.

If you describe the nature of the task you want to perform,
someone might be able to suggest a better mechanism for
expressing it.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Oct 2006 21:05:07 +0200

On 26.10.2006, at 18:24, Gopalan Sri wrote:

> to support

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

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Oct 2006 20:58:48 +0200

Gopalan,

could you reveal the use case that makes you think you need the POST  
capabilities?

Jan

---

From: "Gopalan Sri" <[email-masked]>
Date: Thu, 26 Oct 2006 15:31:07 -0400

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_Open
Search_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-masked]] 
Sent: Thursday, October 26, 2006 3:05 PM
To: Gopalan Sri
Cc: [email-masked]
Subject: Re: Adding POST capability to atom:link

	to support

	something like this:

	<link rel="next" href="http://example.com/"
type="application/atom+xml"

	action="POST">

	    <parameter name="q">

	        <xxx:Payload/>

	    </parameter>

	</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

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Oct 2006 22:02:10 +0200

Gopalan,

On 26.10.2006, at 21:31, Gopalan Sri wrote:

> 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.
If you aim to provide a REST interface, do not mimick a query  
interface (at least not a complex one). Think of your 'asset space'  
in terms of pre-defined, useful collections that you expose as  
resources (feeds) and provide light weight query interfaces to them  
that fit with GET requests.
Think in terms of browsing and drilling-down; REST interfaces guide  
the client into the content instead of assuming the knowledge to  
construct
a query does reside in the client.
This, BTW, avoids coupling your clients to the local data model  
specifics.

Jan

"The Web doesn’t do generic query"
<http://www.markbaker.ca/blog/2006/08/09/sparql-useful-but-not-a-game- 
changer/>

> 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.
>
> 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.
>
> 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

---

From: "Thomas Broyer" <[email-masked]>
Date: Fri, 27 Oct 2006 08:24:29 +0200

2006/10/26, Gopalan Sri:
> 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.
>

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