- From: John J. Barton <John_Barton@hpl.hp.com>
- Date: Wed, 12 Feb 2003 16:37:09 -0800
- To: "David Orchard" <dorchard@bea.com>, <xml-dist-app@w3.org>
At 02:00 PM 2/12/2003 -0800, David Orchard wrote: >Interesting. I think we might have a disagreement about the scope of >representations. I assert that in ALL cases of messages using the HTTP >binding, a representation is transferred. Not just for the WebMethod As I understand "representation" in the web context, the phrase "a representation is transferred" weakens the critical meaning of representation as an instantiation of a resource. >feature wrt SOAP. In the case of a "non-RESTful" SOAP usage, such as the >classic getStockQuote inside a POST, there is still a representation being >transferred. This is exactly similar to an HTML POST of a form, where a >representation of a form is transferred, and then a representation is >returned. So REST isn't limited to just WebMethod IMO. > >I further assert that whenever URIs are used, representations are >transferred. HTTP is indeed designed to be extremely friendly to REST >transfers, but representation transfer isn't limited to HTTP. For example, >ftp transfers lack the ability to add the representation and message >metadata that HTTP supports using HTTP headers. But it is still a >representation transfer. In my opinion FTP does not and cannot transfer representations. That is why they call it the **FILE** transfer protocol. It does not transfer representations of resources. It transfers files. Its intent is quite different from HTTP and this difference is exactly why "representation" was invented. >My point is that there is a distinction between transferring >Representations, and following the REST constraints. I know that might seem >a little strange. But the case of the HTML POST is what really cleared >things up for me. The POST result isn't "on the web" because you can't >"GET" it, but so what? It's still a web page, and representations are >transferred. Just because the resource isn't "on the web", doesn't break >the idea that representations are transferred between resources. As I understand them, representations are returned by servers. Web resources cannot transfer or be transferred so I don't know what the phrase "representations are transferred between resources" could mean. >Now I must admit I haven't thought through the notion of representations >over TCP or UDP. I guess if they don't have URIs, then they wouldn't be >about representations.... I'll have to ponder that. That might be an >interesting boundary condition. Representations do not have URIs over HTTP either. Representations are not a concept that apply at the socket level so you can't find any boundary there. The closest analog for the representation/resource pair that I know is the OOP concept of implementation/interface. Trying OOP on every single application design is ok, but it won't always be the most appropriate approach. As far as I can see a SOAP message need not represent any resource and it rarely would be one of many alternative representations for a resource. The connection of SOAP to Web is just the use of similar technology (XML, HTTP, and URIs). Its just a different thing. >Cheers, >Dave > > > -----Original Message----- > > From: Noah Mendelsohn/Cambridge/IBM > > [mailto:noah_mendelsohn@us.ibm.com] > > Sent: Wednesday, February 12, 2003 1:44 PM > > To: David Orchard > > Cc: 'Mark Baker'; xml-dist-app@w3.org > > Subject: RE: What is a SOAP Message > > > > > > I'm not so sure I see SOAP as being always REST and representations. > > Certainly we have gone a long way to make it possible to use > > SOAP in that > > manner, and I believe that such usage should be encouraged wherever > > practical. Still, I believe that use of REST is optional, as > > is use of > > HTTP. I think I'm correct in saying that the term > > "representation" is > > best used in the context of REST. > > > > Consider a binding of SOAP to some transport such as MQ series. That > > binding may support the WebMethod feature, and hence > > operations such as > > GET and POST, but it need not. I don't see anything in SOAP that > > requires all such uses to map to representations, or even to naming > > destinations with URIs (though that is encouraged with a SHOULD, as I > > recall...I'm disconnected at the moment and can't easily > > check the text.) > > > > SOAP can be used for many levels of messaging. It could be used as a > > structured replacement for or enhancement to UDP, for > > example. Of course, > > at some trivial level one can map every conceivable message > > to something > > like REST. After all, maybe even an individual IP packet can > > be viewed as > > updating the state of some resource at its destination, but we don't > > conventionally view IP or UDP that way. > > > > So, I think that terms like "representation" are best used in the > > specific, admittedly common case where SOAP is used with a > > binding that > > supports the WebMethod feature, and hence REST semantics. I > > don't see > > how every SOAP message is by definition carrying a representation of > > something. > > > > ------------------------------------------------------------------ > > Noah Mendelsohn Voice: 1-617-693-4036 > > IBM Corporation Fax: 1-617-693-8676 > > One Rogers Street > > Cambridge, MA 02142 > > ------------------------------------------------------------------ > > > > > > > > > > > > > > > > "David Orchard" <dorchard@bea.com> > > Sent by: xml-dist-app-request@w3.org > > 02/10/2003 01:11 PM > > > > > > To: "'Mark Baker'" <distobj@acm.org> > > cc: <xml-dist-app@w3.org>, (bcc: Noah > > Mendelsohn/Cambridge/IBM) > > Subject: RE: What is a SOAP Message > > > > > > > > I believe that your counter example is still a representation. It's > > simply > > a representation of a request. Same way that form data > > encoded into a POST > > is a representation of the form. > > > > In my mind, the web is about exchanging messages. In those > > messages are > > representations and message metadata - and that > > representations consist of > > representation data and metadata. In typical web usage, the message > > metadata and representation metadata are HTTP Headers. > > > > Even RPC-style SOAP messages are representations (the > > allegedly "bad" SOAP > > POST examples). Therefore there is a direct and easily describable > > relationship between SOAP and the Web. Something like: > > - SOAP Messages are Web Messages, with content-type soap+xml > > and related > > processing model. Separately, this is an additional > > constraint upon the > > web > > architecture. Probably some motivation about what properties > > are achieved > > by this would be helpful in the ws-arch document. > > - SOAP Messages contain representations. Where I get a > > little fuzzy is > > the > > relationship of the envelope to the representation. It seems > > to me that a > > SOAP representation is an envelope + some stuff outside the envelope. > > Indeed the content-type defines more than just the envelope. > > > > The point being, the SOAP architecture fits very well into the web > > architecture, once one clearly defines the relationship between these > > terms. > > > > Cheers, > > Dave > > > > > -----Original Message----- > > > From: xml-dist-app-request@w3.org > > > [mailto:xml-dist-app-request@w3.org]On > > > Behalf Of Mark Baker > > > Sent: Tuesday, February 04, 2003 8:39 PM > > > To: David Orchard > > > Cc: xml-dist-app@w3.org > > > Subject: Re: What is a SOAP Message > > > > > > > > > > > > +1 to Noah's last message, but I also wanted to respond to Dave's > > > questions ... > > > > > > On Tue, Feb 04, 2003 at 07:08:09PM -0800, David Orchard wrote: > > > > woah, that seems a bit extreme. > > > > > > > > Does that mean if I have a method in an HTML form - like > > > GetStockQuote :-) - > > > > that the HTML result isn't a representation as well? > > > > > > No, response messages of any kind are almost always representations, > > > independant of the form of request message. > > > > > > - getStockQuote("SUNW") returns a representation > > > - GET /foo returns a representation > > > > > > As an example of what it means to return a > > non-representation, imagine > > > sending a request, and getting a response that was really another > > > request that the protocol said you had to treat as a > > request, not just > > > opaque data. > > > > > > > So dereferencing URIs can result in representations and > > > non-representations? > > > > > > Just representations. > > > > > > MB > > > -- > > > Mark Baker. Ottawa, Ontario, CANADA. >http://www.markbaker.ca > > Web architecture consulting, technical reports, evaluation & analysis > > ______________________________________________________ John J. Barton email: John_Barton@hpl.hp.com http://www.hpl.hp.com/personal/John_Barton/index.htm MS 1U-17 Hewlett-Packard Labs 1501 Page Mill Road phone: (650)-236-2888 Palo Alto CA 94304-1126 FAX: (650)-857-5100
Received on Wednesday, 12 February 2003 19:37:15 UTC