The common scenario: we have web client and we have server, between server and client we must tranfer data some how, we use REST, now we need to choose how to implement REST.
In general most services use custom protocols, but Microsoft have introduced long ago OData, specification how to request and update data with the RESTFull services. Here I expore pros and cons of that implemetation, also will compare it with REST services implemeted by the means of ASP.Net MVC.
So strating from WCF Data Service (OData), when you need service just for requesting / filtering data it is prefect, you just implement DataProvider class, suply it with IQueriable properties and inject the instance in DataService class via constructor template parameter (detailed drill here, also you could reference to this article to clear further details of this post).
Now you want to update your data, it is the hard part. You could do this by implementing IUpdatable for you data provider (with his 15+ methods, that is a lot), in which case all updates for all resource pipe through the same methods, which is not good from code isolation prespective (separarted resouces better to be updated via separated classes).
Another option is to use WCF data service toolkit which give you ability to update separated resources in separated classes, but from my point of view do it "too separatedly", every relation updating is now have own separated method (even thre one for each CRU operation). And of cause this project has latest commit in 2011 which is ridicolous.
So now explore implementation of web services with ASP.NET MVC, first of all they support whole OData protcol for quering (even use the same codebase). Second, they have much better implementation for CRUD operations (IMHO), all updates are piped via controller methods, and all data which is passed from client, get to the methods already bound to the service object structures (even complex objects), so don't bother about refernce properties!