Re: Relocating Web services

On Fri, Apr 26, 2002 at 10:09:37AM -0400, Anne Thomas Manes wrote:
> > On Thu, Apr 25, 2002 at 06:31:45PM -0400, Anne Thomas Manes wrote:
> > > So here's the question: do the application semantics of HTTP
> > define the Web
> > > architecture? Does the abuse of HTTP POST constitute a
> > violation of the Web
> > > architecture?
> >
> > Yes.
> 
> Aren't other protocols (SMTP, FTP, etc) part of "the Web"?

SMTP isn't, yet, but could easily be.

FTP, at least retrieval, definitely is.

They are part of the Web because they have been "engulfed" by it.
That is, HTTP's application semantics are general enough to "cover"
FTP and SMTP interactions.

To engulf a system, the Web doesn't have to cover it completely,
just the common use.  For example, for FTP, the GET semantic
has "replaced" FTP RETR (as in, replaced an explicit invocation by an
FTP client with a hyperlink click (aka GET)).  The Web hasn't yet
absorbed FTP PUT, but could do that too.

SMTP is almost entirely just POST.

POP has pretty much been engulfed, because most people use a Web email
client for the last-hop.

> > I've been saying all along that there *is* a way to do what Web services
> > are trying to do, but in a manner consistent with Web architecture.  I
> > would bet that your customers would be really interested in this.
> 
> I encourage you to develop your own REST-based approach to doing Web
> services and go out and try and sell it. Good luck to you.
> 
> I'm not about to follow your lead, though. My customers want SOAP, so that's
> what we're building.

Fair enough.  Good luck to you too.

> One thing that I've learned over the years is that you can't tell customers
> that they're wrong. Customers will use and abuse technology as they see fit.
> Customers have been abusing the application semantics of HTTP POST right
> from the beginning. You won't convince then that your way is better just
> because it doesn't violate the Web architecture. You need to show them
> tangible benefits to convince them to adopt a new programming model --
> benefits that they can't obtain using their current approach (being "better"
> isn't sufficient). What makes you so convinced that SOAP won't provide them
> with acceptable scalability, interoperability, safety, etc?

The years I've spent studying why the Web was so successful.  SOAP
shares none of the really important characterisitcs of the Web that
made it successful.

I agree that telling a customer they're wrong is a bad idea, especially
if they came to you looking for that tech.  But when you approach them,
and describe how to solve their problems while reusing so much of what
they already know about the Web, my experience has been that they're
all ears.  Then when you *show* them, whammo.

> One of the core features of SOAP is that it's transport independent.

There's that word again, transport.  HTTP is not a transport protocol.
It *might* be good to be transport indendant, but it is *bad* to be
application independant.  Abstracting away HTTP abstracts away your
application semantics.

> REST is a wonderful thing. It's an incredibly powerful disruptive
> technology. It has changed the way people search for and obtain information
> and entertainment. It's changing the way people compose information. It's
> having a huge impact on every form of publishing industry (news, magazines,
> books, music, movies, etc.) But that doesn't mean that it should supplant
> all other forms of distributed computing -- not even all forms of Web-based
> communications.

Time will tell, I suppose.

Thanks.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Friday, 26 April 2002 10:23:01 UTC