Subject: How to do RESTful SEARCH (was Re: Adding POST capability to atom:link)

From: Lisa Dusseault <[email-masked]>
Date: Thu, 2 Nov 2006 12:06:19 -0800

On Oct 26, 2006, at 1:02 PM, Jan Algermissen wrote:

> 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 is an interesting assertion about REST.  I don't yet agree with  
it as stated though I might after further discussion and  
elaboration.  To provide a possible counter-example, I always found  
the HTTP SEARCH proposal <http://www.greenbytes.de/tech/webdav/draft- 
reschke-webdav-search-latest.html> to be RESTful because
	- The results of a search are returned as a set of resource identifiers
	- It doesn't necessarily break for dynamic resources as long as the  
server can handle that
	- It doesn't break the layering of representations, or use of  
connectors, or caching of resources
	- It's general -- can be used for WebDAV resources but also for any  
HTTP server, CalDAV resources or probably (with some thought) Atom  
resources

A server that instead provides light-weight query interfaces as you  
describe, or guides the client into the content, does not work with a  
client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom  
authoring client); correct?

Lisa

---

From: Ernest Prabhakar <[email-masked]>
Date: Thu, 2 Nov 2006 12:18:30 -0800

> describe, or guides the client into the content, does not work with  
> a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom  

My understanding (for what it is worth) is that REST *requires*  
hypermedia.  Your choice of hypermedia then constrains your problem  
domain.  Once you select a domain (HTML, Atom, whatever), then to be  
RESTful it is important give clients within that domain a way to  
discover the appropriate syntax using hypermedia.

It sounds like you're asking about the protocol independent of how it  
is presented on the Web.  In that case, I think it is fine to say  
that, e.g., SEARCH *can* be used RESTfully, but I don't think it is  
*necessarily* RESTful unless we know the rest of the application.

My $.02.

-enp

On Nov 2, 2006, at 12:06 PM, Lisa Dusseault wrote:

>> 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
> This is an interesting assertion about REST.  I don't yet agree  
> with it as stated though I might after further discussion and  
> the HTTP SEARCH proposal <http://www.greenbytes.de/tech/webdav/ 
> draft-reschke-webdav-search-latest.html> to be RESTful because
> 	- It doesn't necessarily break for dynamic resources as long as  
> the server can handle that
> 	- It's general -- can be used for WebDAV resources but also for  
> any HTTP server, CalDAV resources or probably (with some thought)  
> Atom resources
>
> describe, or guides the client into the content, does not work with  
> a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 2 Nov 2006 22:31:44 +0100

Lisa,

first, I think I misread Mark's point when I quoted his blog entry:

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

He does talk about hiding the actual query by merely passing in  
parameters; he does not talk about dividing the query space into  
subsets. Sorry about that.

On Nov 2, 2006, at 9:06 PM, Lisa Dusseault wrote:

> draft-reschke-webdav-search-latest.html> to be RESTful

I did not mean to say that using very many parameters was breaking  
REST, I only meant to say that dividing the space is propably  
decreasing the level of coupling as the client needs to know fewer  
parameters. Of course it needs to OTH understand the meaning of the  
subsets but it might already do that anyway. Hard to evaluate in the  
absence of the domain context.

Maybe think about a resource representing all items of 'last week' as  
opposed to providing start-date and end-date parameters to narrow  
down the result set to 'last week'.

> because

I wouldn't say so; the question of MIME type is orthogonal to the  
question of parameters vs. collections. Or am I misreading you?

Jan

---

From: "Mark Baker" <[email-masked]>
Date: Fri, 3 Nov 2006 16:17:52 -0500

On 11/2/06, Lisa Dusseault <[email-masked]> wrote:
> This is an interesting assertion about REST.  I don't yet agree with it as
> stated though I might after further discussion and elaboration.  To provide
> a possible counter-example, I always found the HTTP SEARCH proposal
> <http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html>
> to be RESTful because

I'm not sure exactly what you mean by that Lisa, but AFAICT, the
results of a SEARCH request does not have an identifier.

A RESTful solution would be publish a form that could be used by a
client to construct a URI that would return the search results (with
GET, of course).

Cheers,

Mark.