- From: Amelia A Lewis <alewis@tibco.com>
- Date: Thu, 01 Jul 2004 14:56:14 -0400
- To: Mark Nottingham <mark.nottingham@bea.com>
- Cc: www-ws-desc@w3.org
On Jul 1, 2004, at 2:11 PM, Mark Nottingham wrote: > On Jul 1, 2004, at 10:34 AM, Amelia A Lewis wrote: >> Although this may cause the mob to rise up and lynch me, I also fail >> to be >> convinced that REST is applicable outside the narrow scope of HTTP. >> HTTP >> was, of course, designed (at least in part) around those concepts. >> Possibly Atom is, too. No other protocol, so far as I know, is, and >> the >> mappings of REST to those protocols are hugely less than convincing. > > Differentiate RESTful underlying protocols from RESTful application > design. Just because some protocols don't support RPC (SMTP, anyone?), > you can still map RPC onto them; why is this different? Why map RPC to anything? RPC RIP, DOA .... Most TCP/IP protocols that use the internet message format, organized around a network virtual terminal (NVT ASCII, text-oriented bodies ... predecessors of HTTP, protocols accessible via telnet and a host-port pair), are designed for command-response interactions, where the command may be large or small, and the response may be large or small. They aren't inherently RESTful because they weren't designed to be, and very often the commands are "anti" RESTful (the silly acronymic flip response above contains at least one bit of truth: it isn't "REST versus RPC", it's "REST versus every other networking paradigm"). If someone wishes to offer a set of verbs, explaining how an interface can be built (independently of an underlying protocol) to use particular facilities that these verbs express, and can show that this information is *necessary* to construction of such an abstract implementation from an abstract description, *and* can then show that there really is a protocol out there other than HTTP on which this stuff works, then I'll be convinced. Otherwise, it looks like stuffing HTTP into the interface. Again. >> Under that circumstance, REST-specific attributes/properties belong in >> HTTP (or HTTP-based) bindings (or perhaps someone wants to create a >> generic "REST" binding?). > > I disagree profoundly; it's not binding information; it's inherent in > the design of the interface itself. And there I disagree profoundly. *shrug* I haven't seen what information in these verbs is necessary to an interface, or what capability they enable that isn't otherwise expressible, or how they can be used outside HTTP. (yes, thanks very much, I've read the REST corpus (it also left me profoundly unmoved, but so it goes; it is a more or less valid way to use HTTP, at least)) Amy!
Received on Thursday, 1 July 2004 14:56:49 UTC