RE: FW: draft findings on Unsafe Methods (whenToUseGet-7)

I disagree that SOAP using HTTP POST is necessarily an RPC mechanism.  Many
folks are providing arbitrary document oriented messages using SOAP/HTTP.
In fact, there seems to be an emerging point of view that document/literal
is preferred over rpc.  So please, let's not say soap=rpc.

Cheers,
Dave


> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Scott Cantor
> Sent: Monday, April 15, 2002 9:29 PM
> To: www-tag@w3.org
> Subject: RE: FW: draft findings on Unsafe Methods (whenToUseGet-7)
>
>
> Keith Moore wrote:
> > my guess is that lots of people will continue to treat HTTP
> as an RPC
> > mechanism no matter what architecture you promote.   for
> that reason
> > alone it's silly to claim that RPC has not demonstrated the ability
> > to be deployed - HTTP as it is often used is a wildly successful
> > (in terms of amount of deployment) realization of RPC.
>
> A realization of RPC, yes. That's the point. Let's keep using it. I
> would have assumed that was what web architecture was about. If it's
> about building the next IDL compiler, my advice is to save
> some time. We
> have plenty to choose from already.
>
> HTTP as a substrate for creating new RPC interfaces? Why? Haven't we
> developers been through enough of them? The web is something
> different.
>
> > the RPC paradigm is more familiar to most programmers than REST, and
> > it's probably easier to understand than REST, and it will be
> > difficult to overcome that inertia.
>
> IMHO, it's much more familiar to a lot of newer developers,
> like all the
> novices who cut their teeth on the web. The problem, if you
> want to call
> it one, is that most of these developers don't know they're using
> designs based on REST, let alone what REST means. And yes, these
> applications overruse POST because they aren't really fully designed
> around these concepts, and partly because of browser realities.
>
> But once you move into web services (real ones, not SOAP), the browser
> constraints disappear and suddenly using all four methods the way they
> should be used becomes an option, and I see no reason not to go ahead
> and use them. If SOAP won't support me in that, I don't see
> much reason
> to do anything but ignore it, unfortunately.
>
> Scott Cantor
> cantor.2@osu.edu
> Office of Info Tech
> The Ohio State Univ
>
>

Received on Tuesday, 16 April 2002 01:21:35 UTC