Re: FW: draft findings on Unsafe Methods (whenToUseGet-7)

On Wednesday, December 31, 1969, at 04:26  PM, Tim Bray wrote:
> Whenever I've done this I've paid at least two prices:
> (a) many useful implementation tricks in the areas of caching,
>     proxying, and so on, are ruled out because I didn't use GET

How is proxying affected?

> For example, it seems
> to me that popular tools such as those provided by Akamai are going
> to have real trouble with Web Services traffic.

I can't speak to what that company can or can't do, but I will say that 
generally, Content Delivery Networks (and other intermediaries) 
shouldn't. I'd like to debunk the notion that "if Web Services just used 
GET, everything would be magically cacheable."

HTTP caching is an optimisation for a particular use case (Web 
browsing/REST), and IMNSHO it's not up to much more, if that. A CDN 
won't have any problem with a Web Service because they'll already need 
to have extra information to implement their own caching and message 
handling behaviours; the cost of introducing a "treat this POST like 
GET" bit, or for that matter a handler for a SOAP caching module, is 
negligible. Arbitrary caches on the network won't have this information, 
but I seriously doubt if servers and clients would give it to them; the 
trust relationship isn't there.

The real problem will be picking out the cache key from the request; 
REST doesn't help this case very much, because there's no mechanism to 
get a canonical Request-URI if it has lots of query arguments piled on, 
and once you do, there's no mechanism to determine which arguments are 
relevant to the key.

SOAP's extensibility (Header) and targeting (actor) mechanisms, along 
with a well-defined processing model are a godsend, compared to the 
heuristics, SHOULDs and implementation nightmares of HTTP caching. There 
are some cases where it would be possible to use unaugmented HTTP 
caching with a Web Service, but they are vastly in the minority, and are 
IMO relatively uninteresting.

Mark Nottingham

Received on Tuesday, 16 April 2002 04:01:36 UTC