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