RE: WSA diffs from REST

+1 to Dave! and then some!

Heather Kreger
Web Services Lead Architect
STSM, SWG Emerging Technology
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572


"David Orchard" <dorchard@bea.com>@w3.org on 09/19/2002 03:16:28 PM

Sent by:    www-ws-arch-request@w3.org


To:    "'Mark Baker'" <distobj@acm.org>, <www-ws-arch@w3.org>
cc:
Subject:    RE: WSA diffs from REST




My comments inline.  I was hoping we'd avoid REST vs web services for a
while longer.

> -----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 11:53 AM
> To: www-ws-arch@w3.org
> Subject: WSA diffs from REST
>
>
>
> Re my previous proposal[1] to include a comparison of Web services
> architecture constraints, and REST constraints - which received some
> support - I've taken a stab at providing some of that text, simply by
> going down the list of constraints that Roy describes, and talking
> about how I see the common use of SOAP+WSDL fitting in.
>
> The list of constraints I'm working from is here;
>
>
> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_s
> tyle.htm#sec_5_1
>
> I left out "code on demand", because it's an optional constraint, and
> Web services haven't used it, from what I've seen.
>
> ==snip==
> 1. Client/server
>
> The SOAP processing model describes the roles of "SOAP
> sender" and "SOAP
> receiver", and the additional role of "SOAP intermediary"
> which combines
> the sender and receiver roles, permitting the separation of
> concerns of
> service provider and consumer.  As such, the Web services architecture
> also adopts the client/server constraint.
>
> 2. Stateless
>
> Neither SOAP nor WSDL attempt to constrain interactions between SOAP
> nodes to being stateless or stateful.  It is quite possible
> to use SOAP
> and WSDL to build both types of services, and this is currently common
> practice with many publically available Web services.  Therefore, the
> Web services architecture does not adopt the stateless constraint.
>

I'll bite on this blatant troll.

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.

The criteria should be at the architecture level, not at the implementation
level.  I would say that web services architecture allows for stateless web
services.

> 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.

>
> 4. Uniform Interface
>
> WSDL exists primarily to define interfaces specific to each Web
> service.  Therefore, the Web services architecture does not adopt
> the uniform interface constraint.
>
> 5. Layered System
>
> SOAP defines a processing model which encourages the clean layering of
> functionality between nodes, including intermediaries which
> comprise the
> layers.  Therefore, the Web services architecture accepts the layering
> constraint.
> ==snip==
>
> FWIW, I see this partly as a means for integrating some of
> the harvesting
> results into the document.  More of that harvesting work could be
> integrated in than I've done here though, obviously.  All suggestions
> for doing this are welcome.
>
> Also, we could generalize this section to include any additional
> constraints we feel that the Web services architecture should
> use - but
> I couldn't think of any constraints that WSA uses, other than those
> listed above.  Anyone?

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.

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!".

>
>  [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0242
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com
>
>

Cheers,
Dave

Received on Thursday, 19 September 2002 22:02:49 UTC