Re: DELETE vs. UNBIND

Jim Whitehead wrote:

> DESTROY: MUST remove binding, MUST destroy state
> [...]
> do more precise operations by
> selecting either UNBIND or DESTROY, where they'll know exactly what the
> server will do.

Mmm, even with DESTROY, the client can't really be certain what's going to
happen in the long term.  Suppose the server crashes hard and gets restored
from last night's backups? (OK, so that's an extreme case, but still.) And, as
I said before, what if you have interrelated resources, and the only way to
DESTROY one is to DESTROY them all? The client needs a way to know.  (One
option: DESTROY requires a Targets: header, or perhaps a body, which contains a
list of URIs; this list of URIs must be exactly the same set as the URIs
which will be DESTROYed; if not, DESTROY will fail and report the correct
list.  Then the client has the chance to check to make sure that the user
really does want to DESTROY all of them before resubmitting the request.  Of
course, if the list changes quickly, this will get annoying; but it's safe,
anyway.)

I suspect that we're covering the same ground that HTTP/1.1 did when they
not-quite-defined DELETE.  Larry, are you listening to this thread? Can you
summarize why HTTP/1.1 declined to nail down DELETE too firmly?

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|francis@ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Received on Saturday, 1 May 1999 22:11:37 UTC