- From: Thompson, Bryan B. <BRYAN.B.THOMPSON@saic.com>
- Date: Sun, 18 May 2003 10:20:24 -0400
- To: "'Anne Thomas Manes '" <anne@manes.net>, "'Thompson, Bryan B. '" <BRYAN.B.THOMPSON@saic.com>, "''Jim Webber ' '" <jim.webber@arjuna.com>, "'''Walden Mathews' ' '" <waldenm@optonline.net>, "'''Mark Baker' ' '" <distobj@acm.org>, "'www-ws-arch@w3.org '" <www-ws-arch@w3.org>
- Cc: "Bebee, Bradley R." <bebeeb@US-McLean.mail.saic.com>
Yes, I think that this is an issue with WSDL. However, I do think that it is important to be able to describe existing web resources for interoperation. -bryan -----Original Message----- From: Anne Thomas Manes To: Thompson, Bryan B.; 'Jim Webber '; ''Walden Mathews' '; ''Mark Baker' '; www-ws-arch@w3.org Cc: Bebee, Bradley R. Sent: 5/18/2003 9:49 AM Subject: RE: Magic - It's not magic. I think we would need to make major changes to WSDL to make it adequately support REST. The central artifact in WSDL is the <portType> (now <interface>). In a RESTful world, the central artifact would be a <resource>. Anne > -----Original Message----- > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > Behalf Of Thompson, Bryan B. > Sent: Sunday, May 18, 2003 2:35 AM > To: 'Jim Webber '; ''Walden Mathews' '; ''Mark Baker' '; > 'www-ws-arch@w3.org ' > Cc: Bebee, Bradley R. > Subject: 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 10:20:33 UTC