[
Lists Home |
Date Index |
Thread Index
]
This message has nothing to do with SOAP, so I've changed the subject.
The REST vision seems to have been implemented imperfectly in HTTP in two
ways. This is not a condemnation -- I can guess good reasons for these
choices and would like to know the history to vet my guesses.
1. Concerns of the method semantics (e.g. idempotence of GET) have been
mingled with the capability of the request language (essentially
unrestricted for POST, not very rich and sometimes constrained in expression
size as well for GET).
2. GET is not actually idempotent, owing to the nearly ubiquitous process
of logging the request URI, including any attached query. This clearly
modifies server state and sometimes causes security and/or privacy concerns.
To work around these issues, some people use POST. The HTTP spec (RFC2616)
sanctions the second workaround directly in section 15.1.3. It appears to
sanction the first implicitly by
a) referring in 9.5 to submission of a block of data for a data-handling
process (which is not restricted to be side-effecting and could thus be an
idempotent retrieval).
b) specifying the return of the query results with the status 200 (in
section 10.2.1).
When an application is trying to do what is essentially a retrieval of
results satisfying a complex query which itself may contain sensitive data,
the choice between using GET and POST is just a tradeoff with unpleasant
aspects on both sides. If you don't expect to need bookmarking of POST
results, the path of least resistance is to use POST, rather than figure out
some transformation (if one is possible at all) of the desired query so it
can be squeezed into a URI query portion, along with a corresponding inverse
transformation on the server.
I suspect that using idempotent POSTs doesn't occur as often as you might
otherwise guess because anytime a significant amount of data is being
transmitted to an HTTP server, it's likely that the owner of the server will
want to retain at least some of it; hence, POST is appropriate anyway.
Examples: oracular applications (personalization, shopping advisors, stock
pickers, etc) which make suggestions or predictions based on a query
frequently need to retain part of the query information (along with feedback
about the quality of the results) to tune the oracular machinery. When
these applications involve two websites (the stock-picking oracle used as a
hidden backend service during page generation by a separate corporation
which actually sells the stock to someone accepting the suggestions),
bookmarking is not an issue as it would be if the recipient of the
suggestions were directly contacting the oracle. The backend
server-to-server method is useful if the front-end website massages the
oracle's suggestions (checking them against inventory, for instance, to
avoid promoting something on backorder).
Jeff
----- Original Message -----
From: "Paul Prescod" <paul@prescod.net>
To: <xml-dev@lists.xml.org>
Sent: Wednesday, April 24, 2002 9:16 AM
Subject: Re: Fwd: Re: [xml-dev] What does SOAP really add?
> 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. Your "query templates" idea works at odds with the Web precisely
> because it disallows you from constructing URIs. If you apply the query
> template on the client side you have no such problem. Given that you've
> lost this key benefit of the Web, it really doesn't matter to me
> (personally) whether you use SOAP, an idempotent HTTP POST or Mark's
> workaround. You've already given up the Web's primary advantage so what
> does the actual technique matter?
|
