[
Lists Home |
Date Index |
Thread Index
]
"Bullard, Claude L (Len)" wrote:
>
> From: Paul Prescod [mailto:paul@prescod.net]
>
> 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. ;)
> "Bullard, Claude L (Len)" wrote:
> >
> > Google is an extremely simple and predictable system. I type in the URL, it
> > sends me a search page. I type in a string, it sends me the addresses of
> > documents that contain or relate to that string. I click on an address, it
> > sends me the document. Not very deep, action wise. The essence of statelessness
> > is that it is all just mail.
>
> >What does that mean? If I'm already lost I'm not going to make much
> >progress through the rest of your message which builds upon this
> >seemingly key point.
>
> 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.
> ... 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....
> >> "Resources are conceptual objects. **Representations** of them are delivered
> >> across the web in HTTP messages....web services will use individual data objects
> >> as endpoints"
> >>
> >> What is in the message? We aren't sending the object. We are sending a URI, yes?
> >> We are sending a message to an address, right? Email.
> >> We might expect something to be sent back. Email.
>
> >So every transfer of bits across a network is email to you? FTP is
> >email?
>
> REST is. It doesn't send or expect state. It expects a representation.
The representation is, in general, the representation of some *state*.
You just can't get at the "raw state" for roughly the same reasons that
OO programmers can't, in general, get at the raw state of objects they
don't own.
> 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. 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). For instance if you
start putting Google parameters in XML rather than in the URI then you
lose the ability to hyperlink to Google queries, or bookmark them or
make RDF statements about them like "this Google query does not return
Len's web page". Putting the parameters in the URI makes the query
addressable.
> 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.
http://www.fileangel.org/docs/DAV_2min.html
> ... In FTP, I have commands.
In HTTP you have commands. They are called METHODS to make them sound
more K-RAD. They are a functional superset of the methods available in
FTP (though perhaps not as optimized). They are also a functional
superset of the methods available in SMTP and POP and NNTP and ...
because URIs are so much more flexible than the siloed naming schemes
available in those protocols.
> ... 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).
> ... 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. And the fact
that Google is stateless is just a fact of that application. Expedia is
an example of a service that is stateful. Each transaction generates a
URI that has behind it all of the state of the process so far. Using
GETs against that URI (and the ones it links to) it should be possible
for the trading partner or a third or fourth partner to sync themselves
up with the transaction.
> 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 dunno that either.
Paul Prescod
|
