Re: FW: LC Comments: Web Method Feature (really: REST & SOAP)

We are getting into the details of REST design, so if I respond again I
will cc: rest-discuss rather than xml-dist-app.

Eugene Kuznetsov wrote:
> 
>...
> >  * Squid can cache based on URIs, method names and cache headers
> 
> Ahm, how does caching work for invoices? I have *never* been able
> to understand how content-caching helps accelerate dynamic content
> such as XML messages which represent transactions traveling across
> the network. It is a nice theory, but I contend no one has ever
> used this in production.

Why would caching *not* work for invoices? The invoice is submitted. It
is given a URI. Then it may be retrieved hundreds or thousands of times
by different processes: spiders, validators, auditors, browsers,
clients. They can use caching.

>...
> >  * Service containers can implement recursive deletes of resource
> > hierarchies (with WebDAV)
> 
> Maybe... would those resources be the purchase orders or the endpoints
> that operate on purchase orders? Not sure. Do non-developers do
> this or want to do this?

If you are not tunneling through HTTP then the answer is that the
purchase orders would have URIs.

> >  * Load balancers can do balancing based on URIs
> 
> No way. Where is the session state? 

There is no concept of a session in HTTP and no reason to add it at the
application layer. If you're using HTTP as designed, the *application*
state is on the client.

> ... Which streams should be given higher priority?

One way is by setting up a resource type/method/client matrix. You don't
have to parse the XML to do that. And even if you did, the more of the
work you can do in standard tools, the more time you have left to spend
on the special cases.

>...
> That's why load balancing first became popular, HTTP-parsing
> capability was almost immediately added to them. (Back then it was
> considered heresy to create a Layer 2 switch that looked inside
> "layer 7" application data, but in retrospect it makes perfect
> sense).

Well now we're at layer 7 and we can encode enough in the layer 7
messages so that we do not have to parse the representation payload.

> >  * Resources can be retrieved for basic processing with "wget" and
> > replaced with "curl"
> 
> Maybe. I can't see customers wanting to do this, but it's probably
> more possible.

Customers express their needs in terms of business requirements. The
business requirement here is "easy to test, monitor, quality assure and
maintain by people who are not professional programmers."

> >  * Internet Explorer can graphically display resource representations
> > (probably using <?xml-stylesheet ...?>)
> 
> I would expect most interactions to be finer-grained than any
> non-developer would want to observe.

Developers are people too. Expensive people. Anyhow, I cannot see why a
telephone support representative would turn down the ability to look at
a particular invoice while they are on the phone in case there is a
question about it.

>...
> >  * You can use Apache to help dispatch messages to the appropriate
> > resources
> 
> Until you need to be able to look at the XML data (e.g. PO's that
> have vendorID="x" should go to server Y).

If you encode the vendorID in the URI then Apache will do that for you
too. Otherwise, you can use a small content-filter to augment the
features offered by the server.

> >  * Apache can do "redirects" when resources are moved or merged
> 
> You can do that with SOAP, right?

SOAP has a notion of resource redirect? Not that I know of. How would
you fashion a SOAP response that said that "this purchase order is now
over there?"

> >  * Any resource may incorporate information from any other resource by
> > reference using XPointer, XLink, etc.
> 
> Most of these don't seem to be getting much traction in the
> field.

Not as standards, but as concepts. XML Schema has ways to incorporate
other schemas by reference. XSLT has ways to incorporate other XSLT's by
reference. XHTML of course has a rich linking strategy. RDDL has etc.
etc. This is bog-standard XML technique used in almost all XML
vocabularies that are designed specifically for the Web and not for
"protocol independence". And off the Web, pointers and references are
also quite "popular" in the software develoment world. ;)

I personally do not believe it will be possible to build large-scale
interoperable software without a notion of resource-pointer *as a
starting point*.

> >  * Any resource may be annotated with metadata either through
> > WebDAV or RDF or both.
> 
> So can SOAP endpoints, right? Do I need to have method names
> described by RDF?

Yes, you can annotate *endpoints*. But how do you annotate *the purchase
orders*? You can only do that if every one has its own URI. And that's
at the heart of using HTTP properly instead of as a tunnel. (thus the
title of the thread: "Web Method Feature")

> > Okay, Squid does not know that the GET means "GET purchase
> > order" but it knows how to cache gets.
> 
> Back to my original point -- may be it can, but I really don't
> want it caching purchase orders!

If you know that they can't change once they are submitted, or have
visibility into changes (as server-side squid does) then you do want it
caching purchase orders.

>....
> Mine does, but in all seriousness -- I don't fail to grasp your
> point. Clearly the benefit of layering is that UDP packets don't
> have to know about SAP purchase orders.

Using your analogy: UDP packets want to know about certain things are
designed to help with them. HTTP messages want to know about certain
things and are designed to help with them.

HTTP still doesn't need to care about the internal structure of your
representations, just as a SQL database isn't hardcoded to a particular
schema. But you don't think of your schema as a layer "on top" of SQL.
You don't go around inventing domain-specific statement types. Rather
you use the four built-in statements on arbitrarily complex data and you
get a massive payoff in that intermediate software layer. The same goes
for networkng protocols. It is not just unnecessary, but actually
counter-productive to try to teach both ends of the communication a
whole new application protocol with its own methods when you could just
teach both ends about the *meaning of the data*.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Monday, 8 July 2002 18:39:20 UTC