I've looked at the changedPage spec a little bit and it's pretty focused on
The HTTP dispatching framework I wrote & donated to Apache is generic across
methods & tries to follow HTTP concepts within a 'object oriented
decomposition' way of thinking, while focusing on easy access by
Essentially, I think the approach to HTTP API's from the Apache Xang project
is just as trivially easy, covers more issues & will last longer.
Dave, I just had an idea - how about if I implement a servlet with this
framework & you & I see how hard it is to integrate in a similar fashion as
From: Dave Winer [mailto:firstname.lastname@example.org]
Sent: Monday, January 08, 2001 11:38 AM
To: Mike Dierken; email@example.com; 'Mark Baker'; Stephen D. Williams
Subject: Re: [CNET] Web services -- a 2001 thing?
Mike, interesting thread..
I have my own two cents to add.
We threw in the towel yesterday with Aaron Swartz's help.
It's a long story. Here's the gist of it.
We decided to try an experiment for a new interface we came up with called
At first we supported only SOAP and XML-RPC.
Aaron coaxed us into supporting HTTP-POST too.
"Let the market decide."
PS: What a silly idea --> getting into a bake-off with a guy named Baker.
----- Original Message -----
From: Mike <mailto:mike@DataChannel.com> Dierken
To: firstname.lastname@example.org <mailto:email@example.com> ; 'Mark Baker'
<mailto:firstname.lastname@example.org> ; Stephen D. Williams <mailto:email@example.com>
Sent: Monday, January 08, 2001 11:22 AM
Subject: RE: [CNET] Web services -- a 2001 thing?
> Why go to the bother of hiding GetLastTradePrice inside a POST body when
> it's clear that the semantic that is trying to be achieved here is
> something approaching GET? Why not define a URL,
<http://foo.org/LastTradePrice?stock=DEF> ? Then you could just GET that,
> even from a browser. If you just want the price, don't set your Accept
> header to text/html, but use "application/x-stock-price+xml" (if you
> wanted to use XML, and perhaps a XML Schema datatype) or "text/plain"
> and set up your app to handle it.
If you are into Java & server side frameworks, there is some code on Apache
that has an 'HTTP Object Server' thing with a set of Java interfaces for
this sort of thing.
There are two parts to the project: a 'dispatching framework', and a
app-definition markup language.
The dispatch framework models HTTP requests as
object/method/parameters/return-types. A pluggable handler determine what
part of the request is the object-reference (usually the URL), which part is
the method-identifier (usually the HTTP METHOD - GET/POST/etc.), where the
parameters live (query terms or 'form input fields'), and what the desired
return type(s) are. These get bundled and auto-dispatched (via Java
reflection) to the target object. Add a new method to the Java object and it
is available over HTTP. There is an interface that gets the actual object
from the object-reference, so you can expose a deeply structured heirarchy
of objects with arbitrary methods on each instance.
It was designed to be callable from browsers, where getting to the HTTP
request headers can be difficult, so the 'method call handler' supports
'tunneling' headers through query terms. So, you can identify new methods
via well-known parameters like do:method=new_func and specify return types
through something like do:accept=text/xml.
So you could get stock prices through something like:
or a service to expose NNTP newsgroups might have:
or a service to expose RDBMS info might have:
If you have access to HTTP headers, you could have just set the HTTP Accept
header to 'text/xml' instead, but from an HTML page that is hard to do. The
dispatching framework tries to make it easier for page authors to do the
same stuff, while letting the server author ignore the details of what part
of the request the text actually comes from.
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:18:13 PDT