Re: Few questions about REST

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