W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

Re: Issue 169: Propose http method in the operation interface to simplify http binding.

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
Message-id: <53844548-CB90-11D8-8719-0050E4707F03@tibco.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT