OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Re: Why REST? (RE: [xml-dev] WSIO- With Name)

[ Lists Home | Date Index | Thread Index ]


From: Paul Prescod [mailto:paul@prescod.net]

"Bullard, Claude L (Len)" wrote:
>>  
>> Admittedly, I am using email very loosely here, a simplification
>> to mean no state is guaranteed, only expected.   For some reason,
>> UDDI has methods that are very precise about expectations.  I want
>> to know why they prefer that over REST because even to me, URIs
>> that identify known sources of typed information are easier.

>Dunno. You should ask them. ;)

You mean "They" aren't on XML-Dev?  I thought everyone who was 
anyone on "The Web" was on XML-Dev.  What a let down.  This web 
services thing must not be very important if they don't even 
know about XML. (poke at MS commercial).

>> It means that all I have to know to work from Google is www.google.com
>> and a possible search term.  

>Right. Because web objects have an extremely simple interface in the OO
>sense and they always support GET if they support anything.

But also because that will always return a search page.  The cognition 
for the transaction is the search term and subsequent terms I submit 
through that user interface.

>> ... After that, it is discovery-based if I have
>> the discipline to stay on track.  However, unless I am very confident,
>> I deal with a response of lots of sources through which I must browse
>> to find the useful ones.

>Okay...I'm losing the thread here....

Precision.  Discovery.  Google is only as good as I am able to cognitively 
recognize a precise term, a precise message to send which it will interpret 
as a request.  Otherwise, I get a few to a few thousand candidates back. 
 
>> REST is.  It doesn't send or expect state.  It expects a representation.

>The representation is, in general, the representation of some *state*.

It's a document, packed in a URI or in the body, it's a document.  

I'm not so sure Fielding did much more than the genCode and GML 
guys did in recognizing that documents are how humans formally 
communicate instructions (ok, gestures, speech acts, etc. but 
these are bits on the wire with character encodings, so, docs).

>> How is that different from packing an XML file in a POST?

>There's nothing wrong with packing an XML file in a POST. XML is just a
>syntax for a message with some semantics. 

It's a syntax until the right interpreter interprets it according to 
the local semantics.  URIness is just address space.  Until it is 
associated to a type (you like MIME), it is meaningless.

>You go wrong when you start to
>mismatch the semantics with the Web's natural data model, which is
>resources, URIs and representations (i.e. REST). 

Ummmm... REST = Document.  Otherwise we are just overloading 
function names.  If we do that, why not just use functions 
(what UDDI does).

>Putting the parameters in the URI makes the query
>addressable.

It means I write the query's name next to its address on the 
front of the envelope.

>> But not FTP.  FTP let's me get and set directories, change file names, delete files,
>> and so on.  

>HTTP also. DELETE deletes files. GET and PUT renames them (though there
>is an HTTP extension called MOVE which is an optimization). Getting and
>setting directories are primarily a convenience for interactive use.

Convenience may be at the heart of UDDI.  Is there anything wrong 
with convenience?  Seems to me we accepted a lot of retrograde tech 
to get the convenience of universal addressing.   I don't particularly enjoy 
stateless programming.  It's a pain in the neck and not very fast. ;-)

>URIs are so much more flexible than the siloed naming schemes
>available in those protocols.

Flexible or just won based on a momentum that then hit a brick wall 
of economics.  We don't want to throw the baby out with the 
bathwater, but saying "on The Web" sells exactly nothing these 
days.  In fact, it raises suspicious eyebrows (which is why 
you are being put through this grilling).  I agree that a universal 
address space has advantages, but really, that is DNS for this 
system.  URIs are a way to put an application on the top of that 
based on naming conventions and letting HTTP be the proxy master. 
If MS had proposed that originally, most of you would still be 
using FTP and WAIS.    <offtopic>The brilliance of MS was realizing 
their bad reputation was their strongest asset when it came 
to directing the evolution of "The Web".</offtopic>

> ...  In email, I send a request wrapped in
> an envelope to an address I know a priori because based on description or
> discovery, I have confidence the mail returned will contain a range of
> messages I expect, or I have to discover that address.

>Yes, but email is queued and thus almost never works at interactive
>speeds. And email almost always involves several intermediaries which
>sucks away even more speed. And as discussed above email has no
>"commands" (although SMTP *does* have commands). 

That is a literal email client.  The point is the problem of the 
a priori agreements based on discovery.  UDDI says that discovery 
should be quick and precise, dedicated not to generalized search, 
but to registries of business types with precise commands for 
drilling down to get the stuff you want when you want it.

>> ...   Google seems to me
>> to be a very inefficient way to conduct a series of business transactions.

>The search part of Google is not what REST cares about. 

Very true.  Discovery is what UDDI cares about.  It is what the user 
cares about.  REST is another way to say, at this address 
(if you know this address) is a document that tells you 
the state of this resource at this time.  UDDI is "in accordance with 
the conditions we have agreed upon to this time".  I need to understand 
how all of the rest of that is done because an address 
is not enough.  In most cases, a name is not enough.

> Why do you think UDDI is designed the way it is presently as methods?

>Objects on the brain. I dunno. Why do you think UDDI was hyped as
>solving problems that only strong AI could solve? 

I missed that bit.   Hype is what we do to get a crowd. 
After that, it is lecture or con.  What I am slowly 
and belatedly learning is that success in business is 
a matter of wiring money to money.  The rest is just 
negotiation.

What I do know is that given the WSIO, powerful forces have 
decided to go forward without REST.  Maybe without food too. 
I'd like to not see another dot. bomb because if these 
particular forces get it wrong, it will be more than a few 
hundred thousand misguided dot.commers on the street 
this time.

To rephrase:  even if it isn't RESTful, even if it isn't 
"The Web" as some polity defines that rather abstract 
incantation, will UDDI work 'well-enough', because 
if it does, then the usual rubric of "running code 
and rough consensus' is met.  On with the wiring.   

len




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS