下面是個人基於學習的理解，有些不一定是正確的解釋和描述，可以作爲你學習的參考，不正確的還望指出：
1，RIA Service基於WCF，但是有一點新的概念
其實我對於WCF的配置和概念到現在不是很明白，主要是同事說，只要這樣配置就行了，其他的不用去了解。再加上覺得配置很麻煩，不可理解，我相信有很多人和我一樣的感覺。
但是WCF其實一種很不錯的，不同的應用程序交互的方式。因爲其遵循“SOAP，WSDl和WS-*的標準，使得Service可以跨平臺讀取和使用，所以不僅MS支持，IBM等其他公司也都支持和參與了這些標準的指定。
熟悉WCF的朋友就知道，WCF服務通過WSDL這種大家遵循的標準來定義一個服務的參數類型和返回值類型，通過遵循這個標準的定義，各個廠商的開發和應用平臺就可以按這樣的方式讀取和使用。並且，這樣的定義語言，各種語言很容易生成訪問的代理類，例如VS的Add Service Reference幫我們生成的代理類，使我們不需要自己構造HttpWebRequest或者WebClient的方式去訪問服務。
但是我們知道，WCF封轉的是一個方法，它就像一個處理，一個服務執行某個特定的任務。這種方法的定義千奇百怪，而且WCF本身只支持GET和POST，這使得它雖然使用起來是容易的，但是它並不遵循Web的某些指導原則。所以很多人認爲REST纔是未來，因爲REST實際上是Web的最佳體驗，一個URI代表某種資源，其使用HTTP動詞GET，POST，PUT，DELETE，HEAD來代表對資源的不同處理方式，這統一了接口。統一接口的好處是大家都遵循同樣的方式，一個URI代表某個資源，URI+HTTP Method+Body，這樣的服務使用方式很明確。你很容易通過HttpWebRequest來構造一個REST API的請求。但是SOAP中，一個URI代表很多處理，通過在Body中來定義參數和要訪問的方法，這樣本身使得第三方很難去構造這種訪問，基本上剩下唯一的方式就是生成代理類，這使得WCF很廣泛在企業內部使用，但是真正的分佈式應用或者跨平臺的卻很少使用WCF的方式，例如你隨便翻看Google，校內，開心網，Facebook之類的開放API，它一定是REST的。
基於這樣一些東西，微軟在近幾年也加強了對REST的支持，大家可能很少聽說OData，這就是微軟自己的支持REST的數據協議，而更重要的像WCF Data Service完全基於Odata，使得企業可以以WCF的方式來提供REST服務。我們看到Windows Azure的所有API都是REST的。
RIA Service和WCF Data Service一樣的，它也提供REST服務，在RIA Service中，不再是我們隨意定義自己的方發名稱，而是必須遵循一定的規則。雖然函數名稱仍然是可以自定義的，但是，重要的是，在WCF中每個方法一定對應一個HTTP動詞，因爲RIA Service會用來向外提供REST服務，它必須統一每個方法的接口，這樣才能用統一的HTTP動詞來對應到某個方法。而不像WCF，因爲WCF不知道每個方法代表的是查詢，或者新增，或者刪除，更新，所以它只是去根據參數和方法名詞去調用對應的方法，這導致了WCF本身的使用不方便，接口不統一，資源地址不明確等一些缺點。
2，爲什麼WCF Data Service？爲什麼RIA Service？
WCF本身有什麼缺點嘛，爲什麼微軟要花比較大的精力構建WCF Data Service。
WCF本身已經是比較成熟的方案，至少就WCF的目標來說，它是比較完善和成熟的。
從上面的分析來看，基於SOAP的方式是早期基於跨平臺協作的提議，一些公司包括IBM，微軟，Sun等巨頭一起制定的數據交互協議。但是我們看到，REST纔是跨平臺，多系統協作的完美方案，所以借用以爲博友的話”WCF的未來是RESTful，RESTful將是一等公民“。
那麼WCF Data Service和WCF RIA Service正是基於WCF的一種提供REST服務的方案，我們仍然按照熟悉的方式去開發，但是RIA Service能幫助我們提供基於WCF的REST式的API，而微軟的REST遵循OData協議，遵循OData協議的好處是什麼，除了遵循一般的REST風格，還支持微軟的利器LINQ集成查詢，使得我們可以使用LINQ對基於WCF Data Service或者WCF RIA Service的REST API進行查詢和操作。
3，怎麼樣實現基於WCF的REST API支持？
但是，目前微軟不可能開發一套新的方案，使我們直接就使用新的方案直接構建REST服務。
至少說，WCF現在技術比較成熟，使用者也比較多，所以微軟的做法是基於WCF來構建REST服務。
事實上，我們還是使用原來WCF的方式去構建服務，我們並沒有去定義這個方法代表GET，那個方法代表PUT，但是看看DomainService的使用方式，發現多了一些限制--每個方法名詞必須遵循一定的方式，例如以Create,Update,Delete等開頭，或者我們要構造自己的方法名稱，但是必須聲明方法某種特性。實際上這就是微軟RIA Service在指導我們構建REST式的API，這樣在RIA Service中，我們定義的每個方法都具有明確的動詞，有了這個基礎，RIA Service就很容易把我們本身是WCF一樣定義的服務轉化爲REST服務。
其實現機制，我們添加一個DomainService，再看一下Web.config，發現多了一個DomainServiceModule，是的，RIA Service將一般的WCF服務轉化爲REST服務就是通過它來處理的，DomainServiceModule接收REST請求，根據資源名稱，HTTP動詞，再加上我們對每個DomainService中每個方法的明確含義，DomainServiceModule就能找到對應的方法。通過這樣的方式，RIA Service將給予WCF的服務轉化成了REST服務。從而保護我們開發者的技術投資
4，爲什麼RIA Service？
其實如果是轉化爲REST API，這不就是WCF Data Service的使命嗎，爲什麼又要特別拿出一個RIA Service。
一看到RIA三個字，我們就知道是支持Silverlight的，其實，RIA不僅僅是爲了Silverlight推出的，它用於所以的客戶端訪問，比如Ajax，RIA Service可以返回Xml和Json兩種數據格式，這使得RIA客戶端能夠輕鬆的讀取和使用數據。
對於Silverlight來說，它還解決一個重要問題，用WCF來開發Silverlight應用程序的朋友一定經歷過這樣的事情，我們往往在服務端來定義邏輯處理，在Silverlight中調用不同的WCF方法，但是其實邏輯應該是在客戶端，因此這往往使得我們的服務端的WCF定義會非常複雜，而且需要經常改動，更要命的是，對於WCF重要的問題是，通常我們不好去維護那些通信類，這些往往都是自動生成的，添加一些如Attribute或者自定義字段往往在重新更新數據服務之後就沒了，所以通常一般的人都會在服務端和客戶端另外構建實體，如此又要做WCF實體到自定義實體的轉換，總之，這些工作看起來都那麼讓人討厭，如果我們花時間去發揮自己的創意設計一段自己的程序，哪怕代碼質量不高，起碼我們自己感到心裏舒服，但是，做那樣的工作，我相信你的鼻子一定在出着粗氣。
我們以前就還準備做自己的VS工具，比如添加對Entity的右鍵，使在更新Entity的同時去更新我們自己維護的實體類，並修改相關的轉換，My Lady Gaga
這是WCF RIA Service出現了，它使我們可以單獨定義字段的屬性，對字段的驗證邏輯，而且這樣的驗證邏輯可以同步到客戶端，使得數據驗證不僅發生在客戶端，也發生在服務端，而且這樣的自定義可以保留，不受任何黑暗勢力的控制。這爲我們帶來了不少愉悅，並減少了很多焦慮。
WCF RIA的另一個重要的功能源於它的REST API，我們前面說過，微軟的RIA Service的REST API完全基於OData，而基於OData協議的REST API可以被LINQ支持，這使得我們可以將邏輯放在客戶端，比如我們想構建一個查詢，只需要在客戶端構建不同的LINQ表達式，而不是要像以前一樣在服務端建立一個新的方法，事實上，我們在服務端只需要放置一個一個實體的數據集，一個新增，刪除，更新的方法，我們就可以在客戶端構建不同的邏輯，因爲RIA Service會將LINQ表達式翻譯成相應REST API的調用。這樣我們就又省了不少事，更不要說RIA Service還直接支持綁定，My Lady gaga！
這裏說一下LINQ，爲什麼什麼東西都可以LINQ，是不是微軟爲每一張技術都實現一種LINQ，使我們使用起來是統一的。這裏當然不是，所有的LINQ都是一樣的，LINQ本身只記錄一個表達式，通過查詢表達式可以翻譯成不同的內容，比如對於SQL就翻譯成SQL語句，對於RIA Service就翻譯成相應的REST API的調用，而對於其他技術，你仍然可以翻譯成你想要的對表達式的解釋，比如對於Windows Azure的Table，我們翻譯成對Table API的訪問，理論上，你可以構建自己的Linq To 你的東西。
5，RIA Service本身的項目結構支持服務重用
前面我說過，我對WCF其實不是很在行，我不知道一個WCF是否可以單獨放在一個程序集，然後一個網站只需要引用這個程序集即可以使該網站提供相應的服務，這好比類似將一個ASP.NET的應用程序放在一個程序集，然後放在另一個空白的網站，是否這個網站也可以使用那個網站的功能。
這些都沒有去實踐過，但是我想ASP.NET也好WCF也好都是基於文件名的資源尋址，只不過不同的後綴名使IIS選擇不同的IHttpHandler來處理，我想如果這個.svc的文件放在一個程序集中，應該是無法路由的。
但是RIA Service卻不一樣，你可以把一個Service完全放在一個程序集中，某個網站只要引用這個程序集，這個網站就可以對外提供這樣的服務，我們看這是爲什麼？
RIA Service用DomainServiceModule來處理請求，DomainServiceModule根據HTTP動詞和URI來確定定位到某個方法，而在RIA Service中，爲了定位到DomainService文件，RIA Service利用的不是文件定位，而是通過反射找到程序集和類，因爲RIA Service的URI不是文件的路徑，而是DomainService所在的命名空間，比如：
namespace XXX.Services
{
public class DomainService1:DomainService
{}
}
這樣的服務路徑不是看你將該類文件放在什麼位置來作爲文件路徑，而是以命名空間來確定路徑，它的路徑就是：
http://www.xxx.com/xxx-Service-DomainService1.svc
我們看到，URI表明我要請求的類的命名空間，你只要到這個命名空間下面找到這個類反射就可以可以找到對應的方法處理我的請求。
所以，這樣基於程序集而不是基於文件路徑，使得服務可以編譯成程序集在其他網站重用。
所以，RIA Service新增一個工程，用於建立RIA Service Class Library，而且不僅服務可以放在單獨的項目，而且連代理類也放在不同的項目，這樣使得代理類也可以重用。
這使得在多個網站需要部署統一服務的特別方便，比如均衡負載或者多服務器的情況，每個後端服務器都要提供相同的服務，這是不是很好的特性呢!
6，總結
本文並沒有描述RIA Service的技術細節，相信跟着一些博客的教程或者SDK，你可以去學習操作。本文只總結一些相關概念，有助於你理解。
但是千萬不要輕易相信我的話，我是一個菜鳥，有一些可能是理解錯誤的，只能作爲參考，也歡迎拍磚！
RIA Service還包含身份驗證等等技術細節，有待你去一個一個掌握，期望對大家理解有一點點的幫助！