couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: Document Updates
Date Fri, 14 Nov 2008 12:22:35 GMT

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


Mime
View raw message