On Wednesday, December 31, 1969, at 04:26 PM, Tim Bray wrote: [...]

How is proxying affected?

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.