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

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

Matthew J. Dovey wrote:
> Firstly, I think this is a worthwhile discussion - whilst there are
> reasons which made sense at the time why SRU/SRW works the way it does,
> the move to OASIS is meant to allow us to re-evaluate those reasons
> which may no longer be sound given changes in approaches to web services
> (or in hindsight weren't actually sound in the first place!)
>   

+1

This effort will ideally be used in many many specs and implementations. 
We should leverage the best of SRU work while making any improvements 
that are necessary. Backward compatibility should not be a goal of this 
work.

>   
>> 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.
>
> In SRU/SRW we've taken abs_path to define the resource (database,
> catalogue etc.) you wish to act upon and the query string to indicate
> the (parameterised) action (e.g. search using this query, return index
> terms starting with "blob") to be taken upon that resource.
>   

Here is my understanding so far...

Based on resources including "RESTful Web Services" pp 233 section URI 
Design" here are some principals I have learned relevant to URI design:

    *

      Expose objects defined by information model as resources

          o

            When in doubt make it a resource

    *

      Resources must be addressable by meaningful URIs (URLs in HTTP)

    *

      URIs should reflect containment hierarchy for resource

    * Use “,” and “;” for separating siblings in a URI representing a
      collection. If order is important use “,”. When order is not
      important use “;”
    *

      All actions must be performed using the uniform interface
      consisting of methods defined by HTTP protocol

          o

            *Do not encode actions into URIs unless the action has been
            modeled as a resource*


It is that last point that I was mostly resonating with when I started 
this thread.

> Re REST - at somepoint I did (more as an intellectual exercise) work out
> how SRU would work using full REST - roughly
>
> http:" "//" host [ ":" port ] [ abs_path
>
> would represent a resource
>   

+1

> You would then use PUT to initiate a query which would return a new URL
> representing the result set
>   

Hmm. That is not how I see it so far.

I thought that:

    * PUT should be used to create resources
    * Queries should be initiated via an HTTP GET


> GET on the result set URL would allow you to cursor through the result
> set
>   

GET should invoke the query. It should also support URL query parameters 
that can control options such as "iterating" through a result set. Note 
I avoid "cursor" as it it implies cursor state being maintained on the 
server between HTTP GET operations which is not RESTful.

> POST would allow you to take actions on the result set, e.g. sort
>   

IMHO, POST is used to modify resources. Sort is just an query parameter 
to the HTTP GET URL for the search.


> DELETE would instruct the server to release any resources used by the
> result set.
>   

To be more precise, DELETE would delete the resource from the server.

The use of HTTP protocol operations in a RESTful way is very well 
covered in page 97 of the REST book under "The Uniform Interface"

> Scan would work in a similar manner.
>   

Scan is a great example of how what used to be an action may easily be 
mapped to a resource called "terms".
In REST that resource has a URL like any other resource:

/mysru/terms

This URL simply returns what scan request would have returned.

The beauty it avoids introducing a new protocol.
> An ATOM approach would work in a similar way.
>
> Another discussion point would be basing the result set responses on
> RSS.
>   

I am in the process of making RESTFull bindings to existing SOAP based 
services like ebXML RegRep.
In that effort we felt that we should focus on ATOM and completely 
ignore RSS.

BTW I will be starting a separate thread on ATOM which I feel is really 
important for simplifying our protocols even further by using ATOM as 
the standard representation for our Response syntax.

Thanks.

-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com