RE: Magic - It's not magic.

I was suggesting that we might begin by offering REST-ful examples for the
existing use case scenarios corresponding to the current set of SOAP
examples for those use case scenarios.  I think that this is a very
practical small step.  While it would not set down a normative model for
how a REST-ful web service must implement those various use cases, it
would set down an example of how a REST-ful web service could implement
those various use case scenarios.

With respect to examples, Amazon has deployed both SOAP and REST-ful
web service interfaces.  There was an article a while back in which
they indicated that 80% of the use was the REST-ful interface - it was more
useful, hence more valuable, for their business.  (Maybe someone can locate
the link w/ Google - I'm in Hungary for W3C, and Google is
coming back all in Hungarian;)

The thing to remember about REST is that it describes the existing
web, including its uses for commerical sites such as Google, Amazon,
etc.  When approaching recommendations for web services architecture,
a REST-ful take would add constraints such as, for example:

 - Create a resource using HTTP POST by sending an XML representation of the
new resource.  A status code of "Created" indicates success and the Location
header holds the URI of the new resource.  (This is an additional constraint
on the semantics of HTTP POST corresponding to a specific use case
secenario.)

 - Send an event using POST.  The XML representation of the event is the
entity body of the POST.  The status code should be "Accepted" to indicate
that the event has been received and that asychronous processing will
continue.  (This is a, different, additional constraint on the semantics of
HTTP POST corresponding to a different specific use case scenario.)

Similar use case scenarios can be defined for other primitive operations.
However, there is probably NOT a REST-ful use case scenario for RPC, but you
get RPC with SOAP so you have a complete solution space.

I don't think that we need to hold up SOAP until we have standardized
REST-ful web services.  Certainly there is work to be done here on
standardization of REST-ful web service semantics and service discovery.  At
the same time, I do not believe that we should accept a definition of web
services architecture that leaves out a REST-ful approach.  If we do both,
then we failing to enable both architectural styles.

REST-ful web services are very practical, as shown by existing services such
as Amazon.  However REST promotes a stronger separation of concerns among
the deployed components which tends to promote better reuse -- poor reuse is
a major source of costs in business systems.

For example, if you design a web application such that the backend data
store using XML resource representations that are created by POST, updated
by PUT, read by GET, and destroyed by DELETE then you have a strong
separation of concerns between your web application controller and your data
persistence.  Further, you can directly reuse the data persistence for
workflow or exposing web services.  (PUT and DELETE have a bad name on the
web.  However, when deployed in conjunction with security services, such as
SAML or Liberty Alliance, there operations can be well described and well
governed by security policies.)

I think that REST-ful web services offer an opportunity for federating
multiple web services into new applications.  An example would combine
semantic markup with news content with process (workflow state)
representations and processing components, e.g., for content classification,
to deliver a specific news aggregation service out of mostly pre-existing
components using business specific workflow models.  This sort of approach
makes strong use of URIs to express links among resource representations as
a means of federating heterogeneous services.  This is an example of a very
"web" approach to developing business solutions that is enabled by a
REST-ful approach, but not by a SOAP approach.

REST-ful web services and SOAP can be an either-or choice for a specific
application, but not for all applications.  They support different kinds of
SOA solutions.  I think that we need them both.

One thing that I think is lacking is the ability to describe existing web
services using WSDL.  I think that this unduly limits the utility of SOAP by
making it impossible to directly describe and integrate traditional web
resources within a SOAP web services architecture.

-bryan

-----Original Message-----
From: Jim Webber
To: 'Walden Mathews'; 'Mark Baker'; www-ws-arch@w3.org
Sent: 5/17/2003 3:38 PM
Subject: RE: Magic


> To understand it (even a little) is to build something.  Go 
> for it, everybody.

I suspect this is not feasible for everyone to do. However, if the REST
contingent would perhaps post a simple application somewhere we could
download, install, and marvel at it perhaps some of these issues would
go
away. Or at least the non-REST crowd could argue on a more informed
basis.

So how about it? If someone in the REST camp writes a simple application
for
(say) Tomcat or IIS and makes it available to the group? If REST truly
is as
powerful as its strongest advocates suggest then this will surely come
over
in the example.

To be honest the notion of epiphany appeals to me (I had one of those
once
and it was just fab), and so I wouldn't mind having one again.

So, I guess in response to this thread I would have to say, "put up or
shut
up."*

Jim

* Appologies if that doesn't translate well from British.

Received on Sunday, 18 May 2003 02:35:02 UTC