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 00:29:16 UTC