Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <85263010-3574-4CA6-97B4-F322D72BBAF2@apache.org>
References: <e282921e0902242116n2cd207c4x7a9d0feced3f10d9@mail.gmail.com>
	 <85263010-3574-4CA6-97B4-F322D72BBAF2@apache.org>
Date: Wed, 25 Feb 2009 10:56:10 -0500
Message-ID: <64a10fff0902250756y947d375h5a476afd708447f3@mail.gmail.com>
Subject: Re: REST, Hypermedia, and CouchApps
From: Dean Landolt <dean@deanlandolt.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=00221532c75846ff480463c04635

--00221532c75846ff480463c04635
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Feb 25, 2009 at 10:33 AM, Damien Katz <damien@apache.org> wrote:

>
> On Feb 25, 2009, at 12:16 AM, Chris Anderson wrote:
>
>>
>>
>> Currently, there is no way for an html attachment to a design document
>> to link to other resources provided by that design document, absent
>> client side scripting, or hardcoding the design document name in the
>> html (neither of which are acceptable).
>>
>> If you are the HTML hosted at /db/_design/foo/index.html and you want
>> to provide browsers a link to /db/_view/foo/bar?limit=10 you can't.
>> You can link to other attachments in the same design document, very
>> easily.
>>
>> One way to fix this it to give the resources made available by a
>> design document a common root. This means we can use hrefs like
>> "_show/docid" to link to a show function from an attachment.  So we
>> get paths like this:
>>
>> /db/_design/foo/_view/bar?limit=10
>> /db/_design/foo/_show/docid
>> /db/_design/foo/index.html
>>
>> The downside is that the URLs are longer (and that the change would
>> break all clients), the upside is the ability to link from one to the
>> other (and thus be part of the web).
>>
>
> I think I'm in favor of doing it the longer way. It's more consistent.  It
> will break stuff every client library that uses views, but each will be easy
> to fix.


Consistency FTW...

The *long url *problem can easily be remedied with rewriting. There are
already a few nice recipes for proxy configurations -- they could easily be
expanded to rewrite all non _ top level endpoints from *foo* to /db/_design/
*foo*/ automagically.

At some point a utility could be added that allows rewriting to be
configured at the local.ini level (for those of us that want to rock those
stylish *my couch is on port 80 *shirts ;)

--00221532c75846ff480463c04635--