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
