Re: [search-ws] [Issue] Encode operation in URL not URL option

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

LeVan,Ralph wrote:
> I've got real problems with REST.  But, I suspect this is a religious
> war, because it feels just like the vi vs emacs debates.
>   

I do not have any religion about REST vs. SOAP. I have mostly done SOAP 
for last 7 years and have only recently discovered the joys of REST. 
Initially I was quite skpetical of REST but now I do find it to be very 
compelling. This is specially true for a search API. From all that I 
have heard, what most people wish for is a simple search API that has a 
RESTful HTTP GET binding and supports RESTful specs like OpenSearch and 
ATOM.

I share some of your healthy skepticism regarding the hype surrounding 
some of these but I also see some very compelling arguments in favour of 
RESTfull HTTP GET and ATOM in particular (more on that later).

> I don't like the idea of a mixed model, with some of the information
> embedded in the url and some in the queryString.  Put the data in one or
> the other, but not both.  

I assume by "queryString" you mean the part of the URL after the "?" ?
I assume by "url" you mean the part before the "?" ?

To avoid ambiguity, lets use the spec definition of what a URL structure 
consists of:

<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-03.html#http.url>

"

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

"

Don't we always have the situation where some information is encoded in 
the abs_path while some is encoded in the query? Nearly every search 
spec I have been involved with has that situation a quite a normal one.

> Here at OCLC, we've agreed that pointers to
> objects in our collections will be of the form
> http://<domain>/<collection>/key.  For my collections I turn them into
> SRU queries under the covers.  I'm happy with that form of url for
> simple things.  Everything I need is embedded in the url.
>   

I am not sure what you meant above and how it relates to the specific 
suggestions I made below.
Could you please clarify. Thanks.

> Ralph
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:farrukh@wellfleetsoftware.com] 
> Sent: Wednesday, October 17, 2007 5:40 PM
> To: search-ws@lists.oasis-open.org
> Subject: [search-ws] [Issue] Encode operation in URL not URL option
>
>
> The current spec encodes operations as  URL parameters. 
>
> It seems more RESTful to:
>
>     * Avoid using URL options whenever information can be endcoded in
>       URL (operation=)
>     * Avoid using verbs when we can use nouns (replace scan with terms)
>
>
> Here are some current examples and proposed changes
>
> Current:
> http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&q
> uery=dinosaur&maximumRecords=1&recordSchema=dc
>
> Suggested:
> http://z3950.loc.gov:7090/voyager/search?version=1.1&query=dinosaur&maxi
> mumRecords=1&recordSchema=dc
>
> Current:
> http://myserver.com/sru?operation=scan&version=1.2&scanClause=dc.title=f
> rog&responsePosition=1&maximumTerms=25
>
>
> Suggested:
> http://myserver.com/sru/terms?version=1.2&scanClause=dc.title=frog&respo
> nsePosition=1&maximumTerms=25
>
>
> Even better, we should consider if we can eliminate the Scan operation 
> all together and replace it with a canonical query whose result is the 
> result of the scan operation. The idea is to reuse a few good primitives
>
> and not bloat the protocol.
>
> Thanks.
>
>   


-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com