RE: section 1, intro, for review


There are 2 issues that seem to keep on getting convolved together:
1) Whether the REST notion of a shared information space is an appropriate
model for EVERYTHING in the web, or just some things.
2) Whether HTTP is the best protocol for sharing the kinds of information
that are required between nodes in the web

We should probably debate these issues separately.  It's pretty clear that
you argue that shared information model, with particular methods for
exchanging that state, is the appropriate model for everything.  Further,
you argue that HTTP has the right type of characteristics for this kind of
exchange, such as methods named GET/POST/PUT/DELETE.

Noah and I share the viewpoint that protocol evolution is a good and natural
thing.  My reason is because I don't think that the everything that we want
to do in the future should be modeled as propagation of a shared information
space.  For example, the assumptions of cardinalities of identified
resources might not hold.  Adn the propagation issues may be different
depending upon the application.   A concrete example that I like is thinking
about reliable delivery of a stock quote message.  From the queue software's
perspective, this is a POST.  But from the stock quote applications
perspective, this is a GET.  So I want to POST a GET request ;-).

Perhaps the real issue isn't http, but whether a shared information space is
the way that we should think about future applications that we want to


> -----Original Message-----
> From:
> []On Behalf Of
> Mark Baker
> Sent: Monday, March 18, 2002 2:54 PM
> To:
> Cc:
> Subject: Re: section 1, intro, for review
> > This is a point which Mark and I have occasionally
> discussed  in private.
> > No doubt, HTTP plays a distinguished role in the Web today
> and for the
> > forseeable future.  Still (and I suspect Mark doesn't
> agree) I don't see
> > why our architecture should imply that the web would
> diminished in quality
> > if HTTP were eventually displaced by other protocols.
> I know I come off as a bit of an HTTP nut occasionally, but it's
> difficult to argue that HTTP is the most wonderful
> application protocol
> ever devised, and at the same time say that it could eventually be
> replaced.  But I do believe that.
> However, whatever replaces it will look an awful lot like
> HTTP, because
> HTTP embodies so many principles that are key to REST and Web
> architecture.  For example, it will have a GET method that
> will be safe
> and idempotent, a PUT method that will be idempotent, a POST
> method, and
> a DELETE method.  It will have a Content-Location "header", or some
> other means of asserting the relationship between a resource and a
> representation.  It will have some form of content negotiation, and an
> equivalent to "Vary".  It will have persistent connections,
> and chunking.
> Hopefully, it will also have mandatory extensions.
> I'll stop there.  I think I've made my point. 8-)
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.

Received on Monday, 18 March 2002 18:26:03 UTC