As far as Microsoft is concerned (today) WCF _is_ the .NET-based technology for RESTful web services and "RESTful .NET: Build and Consume RESTful Web Services with .NET 3.5" is all about the WCF approach.
However at the very core WCF is a framework for building "message-based" communication systems. Exchanging "resource representations" in HTTP requests and replies (i.e. messages) is part of a "RESTful web service", however it covers only a small portion of the RESTful philosophy (and requirements).
Implementing RESTful web services in WCF can feel like "forcing a square peg into a round hole" and in many cases "RESTful .NET: Build and Consume RESTful Web Services with .NET 3.5" will provide workarounds to force WCF to do (or merely approximate) "the right thing".
This is history repeating itself. In the Java space both JAX-WS 2.0 and Apache Axis2 tried to bolt "REST" onto message-based frameworks. Both, for all intents and purposes, failed (as far as their REST functionality goes). This was finally rectified with the introduction of a dedicated framework for the implementation of RESTful web services: JAX-RS (Jersey is an implementation from Sun Microsystems).
In the .NET space there isn't a dedicated framework for building RESTful web services (yet). However some practitioners are suggesting that (currently) ASP.NET MVC could be a reasonable alternative to WCF.
For an example see "Building REST Services Using ASP.NET MVC Framework"
from "Effective REST Services via .NET: For .NET Framework 3.5"
Effective REST Services via .NET: For .NET Framework 3.5
Ultimately your business requirements and architecture may lead you to favor WCF, ASP.NET MVC, or some other framework. You need to be aware of what your options are.