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:
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
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
- 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?
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
Lisa
