I've had some experience creating web services. I've been involved in a couple of major SOA projects and even had a go at writing my own web service test tool: WsdlWorks, although I've sadly not had enough time to finish it off. So I've been soaked in SOAP (sorry) for quite some time, especially the Microsoft way of doing it. I've been aware of an alternative web service universe, REST, for a while too, but I dismissed it for lacking tooling and widespread adoption. However, in response to a comment on my 'REST as Betamax' blog, I went out and bought RESTful Web Services by Richardson & Ruby. Yes, it's one of those books, you know, the ones that totally kick you out of your rut. After reading it I've had my mind comprehensively changed. OK, so I'm of weak and easily lead by a good argument, but R&R's arguments for REST are pretty compelling. The core goodness is the linkability of RESTful services; the way that every resource (think object) has an individual URL which allows true hyper-linking of machine readable information. It's the restoration of HTTP to it's throne as the core of the World Wide Web. They show that SOAP is not only needless complexity, but actually a step backward.
As for lack of tooling, I was impressed by how nicely Ruby on Rails supports REST and it leads to the obvious conclusion that the new MVC Framework will make an excellent REST platform, especially with its powerful URL Routing engine. However, for the time being 99% of MS shops will not embrace REST no matter how powerful the arguments are for it. If they're keeping up to date they'll be writing RPC based web services with WCF, if not, they'll still be annotating stuff with [WebMethod]. But, if you hired me and gave me a free hand, I'd definitely go with REST.
Reading this book has just reinforced my view that Microsoft spends most of its time playing catchup with the rest of the software world. Thinking about it, none of the books that have had the most influence on the way I write software mention Microsoft tools.