- From: Siarhei Biarozkin <sberyozkin@zandar.com>
- Date: Thu, 18 Sep 2003 17:48:46 +0100
- To: "Mark Baker" <distobj@acm.org>
- Cc: <www-archive@w3.org>
Hello Mark, > > Can you give a simple example of an unRESTful use of doc-lit SOAP ? > http://www.pocketsoap.com/weblog/SoapInterop/r3/doclit.html > > There, "echoPerson" and "echoDocument" are the operations, which are not > uniform. But they are just WSDL tokens which help with the code generation.They inform a client what needs to be done in order to get Person or Document representation. For ex, echoPerson could translate into the uniform operation POST like this : POST http://data.org application/xml+soap; action="Person" which can be considered being equivalent to http://data.org/Person The control attribute 'action' combines with a containing resource http://data.org. For a server ir means (irrespectively whether 'action' is present or not) that echoPerson() operation must be invoked underneath, but it's an implementation detail. Perhaps, for a doc-lit SOAP, an "action" attribute could be renamed to "resource" ? Also, may be instead of being specified as an attribute of the mime type, it could be appended by a tool to a POSTed URI ? Additionally, it could be recommended that in WSDL it's should be set to a 'noun' value, for ex to 'Person' instead of, say, 'echoClient'. It's interesting that while a doc-lit SOAP service is early bound (I mean that a client proxies are generated upfront, etc), it still allows for an identification of resources, and as such, for their visibility. What do you think ? > Can you point me to one that you think is RESTful? http://www.pocketsoap.com/weblog/SoapInterop/r3/doclit.html :-) > > Rpc/Encoded use of SOAP can't meet (by design) any of REST > > constraints, can it ? > If the encoded operation is uniform, then it would meet the uniform > interface constraint. I'm not sure I understand/agree. Encoded operation could be uniform only in the scope of a given service and it'll be tunneled as part of a higher level uniform operation POST. It seems that a uniform encoded operation will look like an encoded document :-) with a common top element. > Right, though I'd want to use a new name rather than "doc/lit". > "RESTful doc/lit", say. Or "state/literal" maybe. I liked your reference to "doc(ument) style" SOAP. It sounds a little bit less restricting than "state/literal". This is from your reply to my email on late-binding : > > In other words, with late-binding, it's a layer which communicates with a > > service(s) doesn't need to get upgraded, while an application layer may or > > may not need to get updated. > > Right, modulo that it's sometimes called the application layer itself. > There's no upper layer, just data flowing within that application layer. Yes, I think I see what you mean now. > There's another option; the data format is generic enough to be able to > communicate the information within other non-generic formats. i.e. RDF. > See http://www.markbaker.ca/2002/09/Blog/2002/11/17#2002-11-rdf Thanks for a link, sounds interesting. I'll print that RDF tutorial again :-) > > It seems that it would also be beneficial for a SOAP client as well, though > > it's probably of less critical importance than it's for a general HTTP > > client. Do you agree ? > Well, up to that last part I did. I would say that it's of critical > importance to any client using a service over the Internet, primarily > due to reasons of visibility (I assume you've read Roy's dissertation). At the moment it's really a fact that a client software may not necessarily need to get updated in order to avail of a new service which seems a main advantage of a late-binding. That's why I thought it would not be as critical for an individual SOAP client sitting in some closed environment to update, but yes, I agree that if it were possible not to update, then it woud be great Cheers Sergey
Received on Thursday, 18 September 2003 12:52:51 UTC