incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject RESTful? (was: Re: Document Updates)
Date Fri, 14 Nov 2008 22:30:41 GMT

On 15/11/2008, at 8:26 AM, Antony Blakey wrote:

> 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.

Thinking about this, it would not only be RESTful to have the server  
root page contain links such as the _bulk_docs URL and a _design/  
index page, it would also make good documentation if it was an HTML  
page. The name of the anchor or the rel attribute could serve to  
indicate link functions.

   <a href='_bulk_docs' rel='bulkDocumentsRPC'>Bulk Document  
Operations</a>
   <a href='_design/'>Design Document Index</a>

I'm guessing that it would be wrong to annotate the _design link with  
a rel because a document isn't a design document by virtue of it's  
URL, and the _design/ URL is really just a view. This suggests to me  
that maybe _design/ shouldn't be hard-coded, but should be just  
another view defined using the existing mechanism e.g. _view/_design.  
This touches on the recent discussion about design docs being passed  
to views.

IMO the reference docs on the Wiki really belong with the code, and an  
obvious feature would be to serve those documents from the server.

I wonder if this idea conforms to this requirement:

"A REST API should spend almost all of its descriptive effort in  
defining the media type(s) used for representing resources and driving  
application state, or in defining extended relation names and/or  
hypertext-enabled mark-up for existing standard media types."

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

Borrow money from pessimists - they don't expect it back.
   -- Steven Wright



Mime
View raw message