W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

Re: WSA diffs from REST

From: Mark Baker <distobj@acm.org>
Date: Thu, 19 Sep 2002 22:48:33 -0400
To: David Orchard <dorchard@bea.com>
Cc: www-ws-arch@w3.org
Message-ID: <20020919224833.C4430@www.markbaker.ca>

On Thu, Sep 19, 2002 at 04:29:49PM -0700, David Orchard wrote:
> You got no pushback and surprise from me because we took august off.  All
> the messages you quote are in august.  Deciding to incorporate a section on
> REST vs Web Services is a very non-trival decision.

You'd agree that Web services are *different* than REST, right?  Since
REST is a known quantity, and Web services aren't, what's wrong with
just comparing the two?

We don't have to do that as differences, if that's not appetizing to
folks.  We could just list the set of constraints that we feel that
Web services have, and leave it at that - letting the reader compare
it themselves.  Would that help?  I don't care much what format we go

> I'm still very disturbed that web services are being held to a higher
> account than web sites.  Web sites that use cookies for state violate the
> constraint of statelessness, yet I just called them "Web" sites.  So if a
> web services keeps 3 constraints and violates 1, it's "out" of the web, but
> a web site that keeps 1 constraint and violates 3 is "in" the web?

No.  This isn't about what's on or off the Web.  It's about what site
gets the most benefit out of the constraints that it chooses to follow
(of course, at a point, when the really important constraints are ignored
then it is about being on or off the Web).

An architectural style defines a set of constraints that when followed,
yield a system with the properties that were desired when the
constraints were chosen.  You *cannot* disregard a constraint without
losing some desirable property.

Users of cookies chose to disregard the stateless constraint, and they
have to put up with the problems inherrent in doing so.  Most
apparently, they mess up the application state engine, since state is
no longer entirely in the hands of the client as it is if statelessness
is followed.  So you end up with weird behaviour around link navigation
pre-and-post cookie setting, that confuses users of that service.

> I get the feeling that the only REST constraint that matters is uniform
> interface.  In which case the other constraints aren't part of the
> architecture at all, and simply useful design patterns.  Is this the case?
> If it is, then let's just ignore the rest of the constraints because they
> don't realistically matter.

As Roy says, the uniform interface is the central feature of REST that
distinguishes it from other styles, yes.  If you want to focus on it,
I'm fine with that.  IMO, it's 97% of what the Web is.

> The desired property I get from using XML is that I can get better developer
> productivity through re-use of tools and knowledge.  Properties aren't just
> the system properties as it runs for individual requests, but also for the
> entire life-cycle of services and how users - including developers -
> interact with the system.  If somebody chooses not to use my XML constraint,
> they have can't re-use xml parsers, translaters, query engines, etc.  To a
> certain degree, they will have "a priori" knowledge of how to use the
> vocabulary.  I think there is considerable value-add of increased developer
> productivity through use of XML.  In fact, that's probably why it's at the
> W3C because of the widespread benefits.

Well, ok.  I'm not sure how you want to resolve the issues I mentioned,
about HTTP GET and SOAP 1.2 being Infoset based.  I suppose it's fine
for SOAP 1.1 + WSDL 1.1 though.

> On the XML format constraint, maybe I should fight my battle at the TAG
> level.  If it gets into the arch doc, then it's yet another example of how
> web services comply with web constraints.

"yet another"?!  We'll see.

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Thursday, 19 September 2002 22:48:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:59 UTC