Re: Binding

Mark Baker <distobj@acm.org> wrote on 01/08/2003 12:19:29 AM:
<snip/>
> 
> > Is it not reasonable to want to accomodate software agents that have
> > this understanding "hard coded" in the software that implements the 
agent?
> 
> It's entirely reasonable.  I'm surprised you thought I believed
> otherwise!  As I said elsewhere, I was trying to avoid mentioning
> Semantic Web technologies for the most part, because I have a good
> idea how I'll be received.
> 
> And besides, I think there's a lot of value in vanilla REST based
> Web services without the Semantic Web.

Okay, then where and by what means does the agent come by this encoded 
knowledge? (the when is fairly obvious... before:)

> 
> > > The difference between WSDL based knowledge, and REST based 
knowledge,
> > > is that REST's knowledge doesn't impact the binding qualities of the
> > > interaction.  So a client written to know how to place trades, can 
do
> > > so with any service that supports the same schemas.  A Web services
> > > approach requires that *both* interface and schemas match up.
> > 
> > Nonsense. You must be assuming RPC style here...
> 
> (I think you and I have been over this before.  I'll try again, but
> from a slightly different angle.)
> 
> Sort of.  You and I disagree on what "RPC style" is though.  I define
> "RPC style" as a style of Web service where the developer defines the
> methods/operations.

Well, maybe that is because when I look at it, the "method" or "operation" 

name is just some information carried in the message. The fact that some 
may
treat that information with the significance that it maps to a method call 
on
an object or static class is implementation detail that the client need 
not
be concerned with. We just went over the territory where you agreed that 
it was 
entirely acceptable for the agent to have a priori encoded understanding 
of the 
messages it will exchange with the service.

Whether the message looks like:

        <myquoter:StockQuoteRequest xmlns:myquoter="..." symbol="IBM"/>
or
        <myquoter:GetStockQuoteRequest xmlns:myquoter="..." symbol="IBM"/>
or
        <myquoter:sfhgwkjg4321hjfjd xmlns:myquoter="..." sdfasdf="IBM"/>

is largely irrelevant. It just happens to be the agreed upon syntax of the
message.

Don't start with the "HTTP GET uri is better..." argument... I have 
repeatedly
said on this list and elsewhere that I agree, there are benefits to be 
gained
from use of GET in many circumstances. We added GET to the SOAP1.2 
binding. 
We've heard it all before.

Many of us on this list and others have REPEATEDLY said that WE AGREE with 
your 
points. We GET it already! (pun intended:) Can we move on to new 
territory?

As for POST... HTTP POST means whatever the resource wants it to mean 
pretty
much. There is no constraint in REST or in RFC2616 that says what the 
entity
body means. I've posted quotes from RFC2616, I won't bother to do so 
again.

Again, if I have a POST that accepts entity bodies of type application/xml
whose root element name is one of the following:
        A) Feedback
        B) Review
and the body of the POST method happens to dispatch processing to 
different
handlers based upon which root element is carried in the entity body, are 
you 
suggesting that this is not a perfectly valid implementation strategy? 

Why is it all of a sudden a problem for Web services if the SOAP/HTTP 
binding
uses POST in a manner consistent with the above, just dispatching on a 
different
set of criteria (child element of the SOAP:Body element)? In fact, how the 
POST is 
implemented is irrelevant, really.

As for POST being used to get something, there are perfectly valid use 
cases
that I can think of off the top of my head where this strategy might be 
applicable
if not required.

Say I have a service that offers stock tips. It is a fee-based service. 
You POST
your credit card and expiration date and you get the stock tip in 
response. No creditcard, 
no stocktip. That simple.

You will argue that the POST should respond with a message that contains a 
content-location
header containing the URI of my stock tip. Well, fine. I could do that, 
but I may have
valid reasons why I might not, and I may not want that representation to 
be cached or the URI 
bookmarked. I have no way of authenticating you as having purchased the 
tip, so I don't
want to expose the material into public URI space lest it be compromised. 
That would cost
me lost revenue.

The material is copyrighted, so I am protected against my customers from 
copying
and distributing the material without my consent. For that matter, I may 
send it to
you via snail mail or email. I may give you an identifier that you can use 
to call me and
ask why I haven't delivered on my end of the commitment within a 
reasonable time. That identifier
may or maynot be a URI. That is quite irrelevant.

Again, you are retrieving a resource. However, there may be perfectly 
valid reasons
why HTTP GET is not appropriate and why a URI identifier might not be 
publicly exposed.
Maybe *behind* my firewall/service there is a completely RESTful Web based 
system at play 
in which the stock tip resource DOES have a URI, but that is MY business. 
The URI is 
for an address behind my firewall anyway and hence would mean nothing to 
you.

        http://192.168.1.20/current/mystocktip.html

How many nodes does the 192.168.1.2 IP address resolve to anyway? 
Mwaaahahahahahaaa!

> 
> This is in contrast to when developers use the methods provided by
> the underlying application protocols.
> 
> Do you see how that relates to this binding discussion?  That an
> application protocol defines the interface to which an application
> binds?

No. See above. Methinks that you are overly obsessed with GET.

> 
> > There is no reason 
> > whatsoever why
> > you cannot design a Web service such that it used a document-centric 
and 
> > RESTful style of interaction.
> 
> Absolutely, so long as there's no method in the SOAP envelope, or a new
> HTTP-like protocol is developed on top of SOAP (i.e. where the methods
> in the SOAP envelope mean the same as HTTP methods; GET, PUT, etc..,
> i.e. they are uniform).

I'm sorry, and why can't we be using SOAP with another protocol, other 
than
HTTP? May I not use BEEP, SMTP, FTP, or WebsphereMQ? Assuming that I may,
would it not be reasonable that I might want to expose the same set of 
SOAP messages through all of these protocols? Sure, YOU consider that 
tunneling
and we've been down that road before. There is NOTHING in REST or RFC2616
that constrains against tunnelled use of the HTTP protocol. People are and 
have 
been abusing it on a daily basis since it was deployed. Are some using the 
HTTP 
protocol in a more natural and RESTful manner than others? OF COURSE, and 
they reap 
the benefits thereof.

> 
> > Are you suggesting that somehow the RPC style of interaction is part 
of 
> > the
> > Web services architecture? Are you suggesting that REST precludes that
> > style? 
> > 
> > Think again. 
> 
> Well, with my definition of "RPC style", yes, I think it's most
> definitely part of the Web services architecture.  I think most Web
> services developers would be quite shocked at the prospect of not
> defining their own network APIs! 8-)

Oh puhleeze! Go rant on their mailing lists then. You are barking up the 
wrong tree here. I believe that you have agreed in previous posts that 
it is possible to build RESTful Web services. Why don't you write a book 
explaining how developers can best leverage the Web in Web services using 
the HTTP protocol binding, that way you may reach the correct target 
audience.

> 
> > > The structure of URI space is *completely* irrelevant, because the
> > > service creates the URIs, and clients use them opaquely without any 
a
> > > priori knowledge of what each one is; the a priori knowledge is in 
the
> > > code that interprets the schemas and understands what it means for 
some
> > > token, such as a URI, to be in a particular place.  The first point 
#3
> > > above demonstrates this.
> > 
> > And your point is what? I believe that you have successfully argued 
Miles'
> > case for him.
> 
> Miles and I are still struggling through that.  We appear to understand
> each other though, but I'm not sure you and Mike are following. 8-/

Oh, I'm so sorry. I guess I am just not smart enough to follow this 
thread.

"Duh, which way did he go? Which way did he go, huh? Duh, yup, yup, yup... 
duh"

> Assuming that your responses indicate interest, I will however continue
> the discussion.
> 
> MB
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624