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

["LeVan,Ralph" <levan@oclc.org>]

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

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