Re: [CNET] Web services -- a 2001 thing?

Date view Thread view Subject view Author view

From: Dave Winer (dave@userland.com)
Date: Mon Jan 08 2001 - 11:37:39 PST

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 rssCloud.

http://www.thetwowayweb.com/soapMeetsRss

At first we supported only SOAP and XML-RPC.

Aaron coaxed us into supporting HTTP-POST too.

"Let the market decide."

Dave

PS: What a silly idea --> getting into a bake-off with a guy named Baker. ;->

  ----- Original Message -----
  From: Mike Dierken
  To: fork@xent.com ; 'Mark Baker' ; Stephen D. Williams
  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.

  http://xml.apache.org/xang/index.html
  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:
  http://localhost/servlets/stocks/SYMBOL?do:method=lastPrice&do:accept=text/xml

  or a service to expose NNTP newsgroups might have:
  http://localhost/servlets/nntp2xml/Microsoft%20XML%20News/microsoft.public.xml/?do:accept=text/xml

  or a service to expose RDBMS info might have:
  http://localhost/servlets/rdb2xml/Northwind/Shippers/?do:accept=text/xml

  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.

  Mike

Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Mon Jan 08 2001 - 11:43:09 PST