RE: A viewpoint on harvesting REST

Apologies, I hit the Send button a little too quickly -- I meant to say I completely agree it's great to have a consistent interface for RPC and document oriented SOAP.

Eric

-----Original Message-----
From: Newcomer, Eric 
Sent: Thursday, August 01, 2002 10:36 AM
To: 'Mark Hapner'; www-ws-arch@w3.org
Cc: 'ws-arch-public'
Subject: RE: A viewpoint on harvesting REST


Mark,

I agree it's important not to confuse an API with a service, and I've long been a proponent of defining a Web service as an entity distinct from its implementation (i.e. the definition of a Web service assumes a separate mapping to an executable program).

However, I also believe it's important not to constrain Web services architecture to generic interfaces or generic APIs.  You may be correct that specific APIs are more brittle than generic ones, but this is a design tradeoff rather than an architectural limit in my view.  

This sort of loose-grained vs. fine-grained debate has raged in the middleware industry forever, as you probably know, and the upshot is both are useful for different types of application requirements.  In this debate I just do not see the sense of imposing an architecture that was successful for hypertext onto an architecture that assumes a mapping to middleware, instead, since middleware design tradeoffs are more important to preserve than generic Web APIs.  

Otherwise we are in danger of limiting the usefulness of Web services to the usage patterns for hypertext.  The arguments that get religious are also especially damaging in my view since those unwilling to compromise or accept another point of view tend to get marganilized and not listened to since they become viewed as unreasonable participants in what is intended to be a consensus building process.

It's also important to recognize use cases for Web services that essentially have nothing to do with the Web.  

Several times suggestions have been made that SOAP is really an application at the same level as HTTP, and probably this makes the most sense.  We may be seeing some movement in the industry toward broader recognition of this requirement, in some of the recent articles describing the difficulty existing firewalls are having handling increased XML traffic.

Eric

-----Original Message-----
From: Mark Hapner [mailto:mark.hapner@sun.com]
Sent: Thursday, August 01, 2002 12:45 AM
To: www-ws-arch@w3.org
Cc: 'ws-arch-public'
Subject: Re: A viewpoint on harvesting REST




Dave,

I'm pleased to hear about the WSDL work on URI description.

In response to the several REST vs RPC concerns:

Given the community's preference for doc literal bindings and its 
reclassification of Soap action to 'hint' status, the community has 
converged on a message design that supports an RPC API view of a service 
but does not require this view to be expressed on the wire.

What I mean is that originally, a Soap RPC endpoint had a very different 
wire 'signature' than a non-RPC endpoint. Now there is no wire 
difference between them.

This is a good development and illustrates the community's natural 
movement toward the center.

While the API preferences of endpoint and client will still likely color 
the way a service is defined it is important that we don't get too 
fixated on a particular API religion and divide up the domain of web 
services into API 'domains' as Soap encoding threatened to do.

WS developers will have a strong interest in the design of the Soap 
messages that define a service. APIs will provide a convenient view of 
these messages but they are not the 'service'. Developers that make the 
mistake of assuming the API is the service will be in for some surprises 
because the only way for them to understand the impact of their service 
on their intended users is to understand the messages it uses.

RPC is a style of API for producing/consuming WS messages. All web 
services should be able to message all other web services at a basic 
level. The quality of communication they have will depend more on the 
quality of the schema they use than their API style.

If their schema is a clone of the Soap encoding schema and has no real 
semantic content they will find that their service will be brittle and 
their ability to communicate will be compromised. This is one of the 
primary dangers of confusing an API with a service.

-- Mark

David Orchard wrote:
> Mark,
> 
> I did some digging into the use of WSDL with GET as part of TAG discussions.
> It appears to me that WSDL can fully describe a URI.  The UrlReplacement
> section shows how parameters can be specified.  I do think the WSDL group
> has a bit more to do in this area - such as more than zero examples of this,
> highlighting it more strongly in the spec, integrating with the SOAP 1.2
> work - but they have on their issues list update to deal with soap 1.2.  I
> do think the limitations of URI encoding versus XML encoding should be
> described in this context, but that seems like a web architecture issue and
> not a ws arch issue.  Especially with experts like Roy Fielding and Tim Bray
> on the TAG.
> 
> I think that we are at an impasse on how to integrate REST with Web services
> from the perspective of methods names.  I believe that the compromise
> position is that web services should expose GETtable URIs, but that any
> other non-safe methods can be done in specific method.  The REST principle
> is that all methods have to be generic.  This is the whole enchilada,
> whether you have generic methods or methods in the body.  I could go into
> paragraphs of prose on why I think that my middle-ground approach is
> reasonable, but I think that won't solve the heartburn that the REST folks
> have about using ONLY generic methods.
> 
> Cheers,
> Dave
> 
> 
>>-----Original Message-----
>>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
>>Behalf Of Mark Hapner
>>Sent: Wednesday, July 31, 2002 12:04 AM
>>To: ws-arch-public
>>Subject: A viewpoint on harvesting REST
>>
>>
>>
>>I would like to present a perspective on REST harvesting that
>>builds on
>>what I found to be a very positive and enlightening
>>discussion on this
>>topic.
>>
>>I find it hard to write this without referring to
>>'implementation' so I
>>ask your indulgence on this.
>>
>>Some observations:
>>
>>HTTP GET and POST are the primary building blocks of the web.
>>Although
>>their use is not always in accordance with the REST architecture, the
>>REST resource model is the best architectural description of
>>the web we
>>have.
>>
>>The Soap header is the fundamental building block for web services.
>>Combined with MIME/DIME enveloping, Soap and its description
>>facility,
>>WSDL, are the best architectural description of web services
>>we have. (I
>>also include the ebXML stack as part of the larger Soap web services
>>umbrella).
>>
>>A conclusion:
>>
>>There is no technical reason why Soap cannot embrace and extend the
>>existing web. It should; and, WSAWG should reinforce its
>>commitment to
>>this goal.
>>
>>
>>What does it mean for Soap to embrace the existing web?
>>-------------------------------------------------------
>>By embrace, I mean fully support the existing REST resource
>>model as web
>>services.
>>
>>Soap WSDL should be able to provide a basic description of a URI, its
>>support for GET, its GET 'query' and the MIME type it
>>returns. Ditto for
>>POST. Soap should provide a binding that allows web service
>>endpoints to
>>offer services at the HTTP level without requiring enclosing
>>Soap wire
>>enveloping on request or response. This will allow Soap WSDL
>>to be used
>>to describe existing web sites and opens them to access from
>>Soap client
>>tooling.
>>
>>Whether a program can 'understand' the HTML it might retrieve from a
>>Soap WSDL described web site doesn't matter. The ability to use web
>>service tooling to do the retrieval is what is important.
>>
>>Many developers find the RPC view of a service a useful
>>abstraction. If
>>a web site wishes to provide a Soap RPC description of itself
>>to cater
>>to these developers, web services should support this.
>>
>>It should be possible to treat the Amazon XML over HTTP service as a
>>first class web service, i.e. as a first class Soap service. As
>>currently defined, the Amazon service that uses the Soap
>>envelope on the
>>wire does so to leverage web service tooling. In the future, web
>>services should be able to pick from a spectrum of Soap bindings that
>>include 'raw' HTTP as well as Soap over HTTP and other protocols.
>>
>>Web services should support a web service resource model that
>>provides a
>>basic level of a priori communication for applications that
>>communicate
>>at the Soap message level. This already exists and is being
>>refined with
>>idempotent request semantics. This will lead to some web service
>>endpoints that cater to a priori access by providing simpler, more
>>generic Soap messages (while some may cater to message level access -
>>all will provide it). Their Soap WSDL description will provide basic
>>message level access information and may provide additional
>>RPC binding
>>info so they can be easily accessed by clients from both the RPC and
>>messaging API layers.
>>
>>Others have already suggested things along these lines. I
>>would like to
>>add my vote for a web service architecture that embraces REST and the
>>existing web while extending the web with Soap.
>>
>>-- Mark
>>
>>
>>
>>
>>
>>
>>
>>
> 
>

Received on Thursday, 1 August 2002 11:16:56 UTC