Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.198.244 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=c5aI8hqT7fSEQPOMUxO4Bktca7zKv20CUJbS20kbUJhp6QzeF8vRaQ+3Vbj8K7z5sg
         5/mdQTX7t43cGB3pLPIYa25eS3YEp681fQWhPibmDMmsoYepxVpqCS+9NAWgmx50inUY
         906esqXVLtlNgT9a57bGl68hbmrPgzGhQAkyI=
Message-Id: <E1BB0975-0CD8-4EB0-8F35-E39D13133297@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: couchdb-user@incubator.apache.org
In-Reply-To: <e282921e0811140940t72b36635xda79de392e56c06f@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Document Updates
Date: Sat, 15 Nov 2008 08:26:14 +1030
References: <27d8d0930811130840t47269d91o9539fae200bcd380@mail.gmail.com>
 <20081113220313.GG15315@tumbolia.org>
 <E41668CB-582E-453E-96D4-F0E1C5ECE5E5@gmail.com>
 <20081113233718.GI15315@tumbolia.org>
 <C9035E5D-EAD8-4A37-8232-89A23EAD75BE@gmail.com>
 <B790E3CA-E0DC-42A4-9032-87CA741CC095@gmail.com>
 <20081114040241.GJ15315@tumbolia.org>
 <A67C8386-AACD-4F22-90E3-870F48818B8D@gmail.com>
 <20081114115348.GA24001@tumbolia.org>
 <B21804B5-6CC6-4292-9CCC-4A5C4EA2811D@gmail.com>
 <e282921e0811140940t72b36635xda79de392e56c06f@mail.gmail.com>


On 15/11/2008, at 4:10 AM, Chris Anderson wrote:

> But I've been thinking about this as well. If we were to attack this
> problem of "High REST" head-on, I think the appropriate course would
> be to define a media type application/couch+json or something. The
> media type's definition would explain how to get from "id" params to
> document URIs, etc.

I think some equivalent to base-uri would be needed to avoid the  
definition of the media type including requirements on the URL  
structure of the server. Either that of the document would include the  
resource URL.

A landing page with URLs for the design documents would also be  
needed. View definitions would need a unique media type because  
currently their meaning is dependent on their location. But maybe I'm  
misunderstanding REST. So easy.

> Doing that is all it would take to be (mostly)
> RESTful. I think the existence of _bulk_docs POST doesn't break
> RESTfulness, either. There's no law that says a system can't define
> RESTful resources alongside RPC endpoints.

Agreed, but IMO Couch shouldn't claim to be at all RESTful if it  
doesn't meet the criteria. It might be REST-like. If some parts are  
RESTful and others not, then the claim should be that it includes some  
RESTful interfaces.

It might seem nitpicking, but the definition of REST is voided when  
things claim to be RESTful that in fact aren't, and it's rarely used  
correctly. I'm not even sure what conformance looks like.

> I'm not sure how meditating on the Zen of REST will help us get
> json-diffs right, but it sure can't hurt.

Sorry, I distracted the discussion when I mentioned _bulk_docs.

I would start working on an implementation of the apply-end of my diff  
proposal, but I don't want to waste time if the powers-that-be don't  
think it's the right way to go.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Some defeats are instalments to victory.
   -- Jacob Riis