RE: WSA diffs from REST

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.

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?

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.

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.

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.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Thursday, September 19, 2002 1:46 PM
> To: David Orchard
> Cc: www-ws-arch@w3.org
> Subject: Re: WSA diffs from REST
>
>
>
> On Thu, Sep 19, 2002 at 12:16:28PM -0700, David Orchard wrote:
> > My comments inline.  I was hoping we'd avoid REST vs web
> services for a
> > while longer.
>
> Me too.
>
> You're making a mountain out of a mole hill here, Dave.  I
> proposed this
> idea a while ago, got no pushback from you, yet received support from
> other WG members;
>
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0249
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0286
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0254
>
> I also received pushback from others, of course, but
> certainly there was
> enough support that I felt I'd move ahead with writing
> something down for
> the arch doc.  That's all this is.  It shouldn't have been a surprise.
>
> > I'll bite on this blatant troll.
>
> It's no such thing.  I felt it was quite fair.  *NO* personal
> judgement was
> exercised in doing this, to the best of my knowledge, just my
> substantial
> experience as a student of distributed systems and software
> architecture.
>
> > I could use the same argument that because the web with
> HTTP cookies allows
> > stateful web pages, and many publically available web site
> use stateful
> > interactions.  Therefore the web architecture does not
> adopt the stateless
> > constraint.
>
> I'm sure you've read this;
>
> http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.
> htm#sec_6_3_4_2
>
> > The criteria should be at the architecture level, not at
> the implementation
> > level.
>
> Software architecture is the architecture *of* implementation;
>
>   "A software architecture is an abstraction of the run-time
> elements of
>    a software system during some phase of its operation.[...]"
> --
> http://www.ics.uci.edu/~fielding/pubs/dissertation/software_ar
> ch.htm#sec_1_1
>
> >  I would say that web services architecture allows for stateless web
> > services.
>
> That's what I said.  The issue is, are Web services interactions
> *constrained* to be stateless; yes or no?  I think by "allow", that
> you're also allowing that they not be stateless, right?  If so, then
> they are not constrained one way or the other, which was the
> basis of my
> conclusion.
>
> > > 3. Cache
> > >
> > > SOAP and WSDL say nothing about caching.  While SOAP caching
> > > extensions
> > > have been discussed, there is currently no requirement that the
> > > cacheability of a message be implicitly or explicitly indicated.
> > > Therefore, the Web services architecture does not adopt the cache
> > > constraint.
> >
> > As before, there is nothing in web service architecture
> that precludes
> > caching.
>
> Of course.  But the issue is not whether caching is supported, it's
> whether caching must be implicitly (e.g. tied to the method) or
> explicitly (with a cache control directive) identified as part of a
> message.  With SOAP+WSDL, there is no such constraint, therefore this
> constraint is not currently part of the WSA, or of the software
> developed with those specs.
>
> Is that not a fair statement?
>
> > 6. XML.  Web services accepts the constraint of using XML
> for sending and/or
> > receiving information.  Some exemptions exist - as with
> other constraints -
> > but web services appears to be more focused on providing
> XML interactions.
> > As compared to the older web, which has almost nothing to
> do with XML, given
> > HTML, CSS, JPEG, GIF, MPEG etc. are the dominant formats
> interchanged.
>
> No, exceptions are not supported if the desired properties of the
> architectural style are to be realized.  If they're not to be
> realized,
> then you're really defining two architectural styles; one with the
> properties resulting from the constraint being included, and another
> style resulting from the constraint being excluded.
>
> Besides, I'm not even sure what kind of useful properties would emerge
> from a constraint like that one.  I think the value-add of such a
> constraint would be zero, but that doesn't in any way prevent us from
> defining a reference architecture which uses XML for everything.  But
> that's independant from the architectural style of Web
> services that I'm
> trying to describe (while describing the differences with REST).
>
> > 7. Extensible interface definition.  Web services accepts
> the constraint of
> > providing interface definitions for web services.  also
> known as the "it's a
> > feature, not a bug, darn it!".
>
> Sure.  Perhaps this would be better moved under the uniform interface
> response though?  i.e. say something like "supports object-specific
> interfaces and constrains that they be described".  I'm not sure what
> you mean by "extensible" in this context, or how that relates to a
> constraint on the architecture.
>
> MB
> --
> 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 19:33:30 UTC