W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2002

RE: A priori; the big secret

From: Damodaran, Suresh <Suresh_Damodaran@stercomm.com>
Date: Wed, 22 May 2002 18:06:50 -0500
Message-ID: <40AC2C8FB855D411AE0200D0B7458B2B07C595C7@scidalmsg01.csg.stercomm.com>
To: www-ws-arch@w3.org

I agree with and support the broad notion of the a-priori protocol,
which I think will support interoperability of systems built with
partial compliance to standard interfaces by allowing discovery
of supported interfaces at each party's side.

However, I disagree with the implementation dependency on HTTP.
I would prefer building the same protocol using SOAP,
and make the binding for HTTP, SMTP, FTP, BEEP, what have you.
This will help wider adoption of this protocol.
(I remember discussing it as the "zero protocol") 
I cannot offer a counter proposition right now, but shouldn't be a stretch.


-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Wednesday, May 22, 2002 1:35 PM
To: www-ws-arch@w3.org
Subject: A priori; the big secret

I'm having a really bad day today, so I thought I'd try to liven it up
by describing the interface that I had in mind for the recently accepted
draft requirement that I proposed about "a priori".

In order to build the most general interface, we need to look at what
things are common about *all* Web services.  Here's a rough list;

- each is identifiable by a URI (or at least that's what our working
definition says).
- each will have a lifetime; at some point it will be created, and some
will eventually disappear.
- each will have state, if you count the "null" state for stateless
- each should be able to be restricted to authorized users.
- sometimes, a Web service might have to relocate
- sometimes, by mistake or intent, a Web service might just not be there

So, here's my stab at the methods and responses.

Proposed methods;

- GET() - used to return a representation of the identity and state of
the Web service.  For example, a GET on a Web service that controls a
lightbulb might return an XML document describing whether the lightbulb
is on or off; <lightbulb state="on"/>
- PUT() - used to set the state of a Web service.  For example, we could
change the lightbulb document, and then PUT() it back, thereby turning
the lightbulb off; <lightbulb state="off"/>
- POST() - used to hand a document to a Web service for processing.
Only the Web service gets to decide what to do with the document.
- DELETE() - requests that the Web service be deleted.  It doesn't have
to delete itself if it doesn't want to.

- unauthorized - you aren't yet authorized, but here's what you have to
know in order to be.  Fill it in and respond back.
- forbidden - sorry, you're not allowed
- not found - sorry, can't find this Web service
- relocated temporarily - for now, please use this other Web service,
but keep checking back here
- relocated permanently - please use this new Web service, and you might
as well forget about the URI you used to get here, since it ain't coming
- gone - sorry, this Web service has been removed

Hopefully you now understand why I'm such a big fan of HTTP and Web

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Wednesday, 22 May 2002 19:07:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:56 UTC