Yaron and I used to fight about (er, "discuss") this. Hi, Yaron :)
He and Jim Whitehead wrote a paper about the property design of
WebDAV that explained their requriements and choices; see:
http://www.goland.org/spe-whitehead.pdf
It might be helpful reading.
My preferred way to do this is to turn
PROPFIND /foo
into
GET /foo,properties
where ",properties" is a site-configurable string. It needs to be
advertised by some sort of site metadata; e.g., in OPTIONS *, or in a
response header (although that's arguably a waste of bytes).
There's also the case of getting the properties of multiple
resources, or filtering the properties you get server-side; this
should also be possible, e.g.,
GET/foo,properties;prop1;prop2;depth=infinity
I totally agree with Roy about WebDAV ACLs, but haven't yet seen any
other model come forth.
Cheers,
On 2006/04/11, at 2:32 PM, Dr. Ernie Prabhakar wrote:
I've always felt there was something wrong with WebDAV, and Roy did
a nice summary of what over on rest-discuss:
On Apr 11, 2006, at 12:40 PM, Roy T. Fielding wrote:
PROP* methods conflict with REST because they prevent
important resources from having URIs and effectively double the
number of methods for no good reason. Both Henrik and I argued
against those methods at the time. It really doesn't matter
how uniform they are because they break other aspects of the
overall model, leading to further complications in versioning
(WebDAV versioning is hopelessly complicated), access control
(WebDAV ACLs are completely wrong for HTTP), and just about every
other extension to WebDAV that has been proposed.
The interesting question for me is what the "right" way to do
properties would be over HTTP. I presume it would require some
sort of convention for a property namespace, which implies non-
opaque URLs. Which in term (in order to be RESTful) would require
the *server* to have some way to tell clients about it, since
clients shouldn't *assume* URI structure.
Any thoughts about the optimal way to do that?
-- Ernie P.
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
--
Mark Nottingham
[EMAIL PROTECTED]
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
