W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2004

Re: Section 1.6 and REST - Can we make this more clear and useful?

From: Mark Baker <distobj@acm.org>
Date: Sun, 25 Jan 2004 02:20:47 -0500
To: Bill de hÓra <bill.dehora@propylon.com>
Cc: www-ws-arch@w3.org
Message-ID: <20040125022047.N3790@www.markbaker.ca>

On Sat, Jan 24, 2004 at 04:54:50PM +0000, Bill de hÓra wrote:
> As for the text, instead of simple v complex, perhaps the doc could 
> talk about classes of problem. Would anyone really object to a 
> document pointing out that REST (sans extensions such as mentioned 
> by Mark Baker) might not be the right style for eventing,

I think it's just fine for "eventing" (if you mean event notifications,
pub/sub, etc..).

I'm also not sure what you mean by "REST sans extensions".  A RESTful
system is one which has RESTs constraints as its own, but that doesn't
mean that it can't have more constraints.  Indeed, it *must* have more
constraints otherwise you'd never interop since REST doesn't say squat
about what data format should be used, for example.

> rm,

Well, there's nothing unRESTful about RM AFAIK.  IMO, it's just a really
bad idea to make reliability that transparent to an app.  But that
doesn't mean one couldn't build RM into HTTP, and queue up GET messages
for retransmission, for example, rather than letting the app retry.

> or 
> high volume TP?

Yes, definitely.  They're almost always stateful, in my experience.

Perhaps you should run with that.

> What REST could add there is operational visibility 
> - a standard means to ask various systems about a given resource (be 
> it a message/transaction/document).


Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Sunday, 25 January 2004 02:21:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:10 UTC