[
Lists Home |
Date Index |
Thread Index
]
[Paul Prescod]
> Third, the extent of the debauchery on the existing Web is often
> exaggerated. Yes, POST is often used for idempotent operations, but
> sophisticated web designers know that to make their results bookmarkable
> they needed to generate URIs for them, whether they read the HTTP spec
> or not.
This is interesting because it there are some quasi-hidden levels that muddy
the waters that Paul thought he had cleared. I have some database-backed
sites that get data from the server using GET operations. The server
composes the sql query based on the properties in the query string. This is
bread-and-butter business of millions of sites. Now Paul says this is good
because the URL (with query string) can be bookmarked, whereas if I used a
POST or perhaps worse SOAP, it would be less desirable because it couldn't.
I'm not very interested in anyone bookmarking one of these queries. There
are hundreds of queries one could have made, why store this one? If you
want the data, save the page, say I. Would you save a bookmark so you could
buy the same book from Amazon all over again? If you want to get other
information, bookmark the page you made the selections from.
Well, that is just about this particular site, not a general conclusion.
But are many many cases where there is really no reason to bookmark a url.
Why not use POST or SOAP for them?
But another hidden layer appears if we think about Semantic Web-like
activities. Now we want a machine (our agent, perhaps) to buy the book, or
whatever, for us. The machine must figure out what to ask for and how.
Does this urge us to use a GET? Maybe not to invoke the transaction, since
we can learn how from wsdl or some such. But to refer to the thing with a
URI, we need a URI, not a POST or SOAP payload. And referring to things by
URI (or really, URI reference) is part of just about every proposal for
SW-like systems - RDF, Topic Maps, DAML, you name it.
The most convenient and definitive URI reference might be one with the
complete query fragment for the item to be retrieved. In turn this would
only be possible if the request could in fact be made by stating a URI
reference. It doesn't have to imply the use of a GET, even, although that
migt make sense (but then what about secure requests?)
Obviously there can be many approaches to deal with these cases. But they
muddy the waters, don't they?
Cheers,
Tom P
|
