- 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
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). Right. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Sunday, 25 January 2004 02:21:29 UTC