On 14/11/2008, at 10:23 PM, Noah Slater wrote:
On Fri, Nov 14, 2008 at 05:35:03PM +1030, Antony Blakey wrote:
I'm not tunneling verbs, I'm just re-using the names of the methods
that would
normally be used as selectors. I wasn't implying anything more than
that.
...
You delete a document using the DELETE verb, yet in a bulk
operation you set
the "_deleted" special attribute. That is in effect tunneling the
DELETE,
using a different representation, within a POST.
A RESTful system should work by exchanging representations of
resources.
As best I understand it, if you want to modify a resource in a way
that is not a
direct update, move or delete you should use a separate media type,
something
like application/diff+json if it existed. A JSON diff could include
ways to
delete and update multiple documents at the same time, a bit like
UNIX diff is
able to specify filenames. This could be used for single or bulk
updates.
Yes, a content-type was something I suggested, but it didn't seem
right. In a strictly RESTful sense, maybe it does make sense however.
Of course, this feels very similar to your original proposal, which
leaves me a
little confused. Throwing about JSON with keys such as "POST" and
"DELETE" feels
very RPC-like. Perhaps the difference is the use of a separate media
type.
These items, such as 'post' and 'delete' can be equated to the
'replace'/'insert' et al of my diff proposal, but operating over
documents rather than JSON trees. The fact that they are so named was
*purely* an attempt on my part to make it obvious what equivalent
(singular) resource operation (identified by HTTP method) was
equivalent to that document-level operation, and was in no way an
attempt to tunnel the HTTP mechanism.
The current way _bulk_docs does deletion doesn't feel right. I do
think there should be some isomorphism between the _bulk_docs
structure and the operations one would do without using the _bulk_docs
mechanism, hence my suggestion (but the second temporal ordering, not
the first operation-type ordering).
I am eager to be corrected by any resident RESTafarians. For me,
REST is a bit
like Zen. Sometimes I think I understand it totally, and other times
I'm
convinced that I don't understand it at all.
I don't think Couch is truly REST. Certainly _bulk_docs isn't. The
fact that there are URI patterns means it's not REST, at least not if
I've understood Roy's recent communications/frustrations, such as http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
.
In particular, point 4 seems to disqualify any system, (including
Couch) that needs the documents in the "Reference" section of the Wiki.
To be REST it has to be just like the web. Using links discovered from
documents, never constructing them according to some scheme.
However, what does it matter? REST certainly is a slippery sucker, but
that may be because we want it to be more generally applicable than it
is. Couch doesn't have to be REST, and I suspect that it in fact
cannot be.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Man will never be free until the last king is strangled with the
entrails of the last priest.
-- Denis Diderot
