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_arch.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 16:46:22 UTC