|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] idempotent POSTs
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@p...> To: <xml-dev@l...> Sent: Wednesday, April 24, 2002 9:16 AM Subject: Re: Fwd: Re: 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?
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








