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
