簡介：
基於 REST 的 Web 服務日益成為後端企業服務整合的首選，因為它比 SOAP 更加簡單。這篇文章介紹了一
個簡單的可擴充套件框架，使用Asp.net Web Api作為 REST 服務的實現。它詳細描述了設計細節，並探討了各種可擴充套件性方法。
概念
REpresentational State Transfer (REST) 是一種架構原則，其中將 web 服務視為資源，可以由其 URL 唯一標識。RESTful Web 服務的關鍵特點是明確使用 HTTP 方法來表示不同的操作的呼叫。
設計原則：
REST 的基本設計原則對典型 CRUD 操作使用 HTTP 協議方法：
POST - 建立資源
GET - 檢索資源
PUT – 更新資源
DELETE - 刪除資源
優勢：
REST 服務的主要優勢在於：
它們是跨平臺 (Java、.net、PHP 等）高度可重用的，因為它們都依賴基本 HTTP 協議。
它們使用基本的 XML，而不是複雜的 SOAP XML，使用非常方便。
基於 REST 的 web 服務日益成為後端企業服務整合的首選方法。與基於 SOAP 的 web 服務相比，它的程式設計模型簡
單，而本機 XML（而不是 SOAP ）的使用減少了序列化和反序列化過程的複雜性，並且不再需要其他作用相同的第
三方庫。
支援：
當前用於構建 RESTful 服務，比如 .Net平臺下基於asp.net api的實現 和 REST 支援使用Microsoft Visual Studio 2012 MVC 4.0模擬支援和Microsoft Visual Studio2013原生支援。
因此本文建議使用更簡單的可擴充套件框架將業務服務公開為類 REST 服務。該框架是輕量級的，採用標準的 Front Controller（前端控制器）模式，非常便於理解。它也是可擴充套件的，可以通過 API 或任何其他整合模式（如 ESB）集
成後端服務。通過使用自定義 XML 序列化程式、json 或任何其他物件到 XML 轉換工具，可以方便地配置資料交換模型。
概述：
在以前的應用程式中，服務通常公開為SOAP web 服務。在這些服務與使用非.Net 技術 （如 Java 或 PHP）的客戶端應用程式整合時，處理 SOAP Web 服務將變得非常麻煩，還涉及到大量的開發和配置工作。
這裡提到的方法通常用於有很多服務、服務可以重複使用，但使用 SOAP 建立快速整合障礙的互操作性和開發成本很大的組織，幫助它們進行服務整合。此外，在內部治理組織不會在企業 ESB 或 EAI 上公開服務的情況下，很難以點到點的方式整合兩種不同的技術服務。
該架構包括 Front Controller，作為接收請求並向客戶端提供響應的中心點。Front Controller 將請求處理委託給包含此框架處理邏輯的 ActionController。ActionController 執行驗證，將請求對映到相應的 Action，並呼叫生成響應的動作。為請求處理、日誌記錄和異常處理這些可以被單個 Action 以及 ActionController 使用的動作提供了各種 Helper Service。
Front Controller 通過讓單個控制器負責傳輸所有請求，從而解決了在 Page Controller 中存在的分散化問題。控制器本身通常分為以下兩部分實現：
處理程式和命令層次結構:
處理程式具有以下兩項職責：
檢索引數：處理程式接收來自 Web 伺服器的 HTTP Post 或 Get 請求，並從請求中檢索相關引數。
選擇命令：處理程式首先使用請求中的引數選擇正確的命令，然後將控制權轉移給該命令以便執行處理。
框架元件
處理典型 POST 請求的這些元件之間的互動如下所示：
如上圖所示，REST 服務配置最初載入，並快取到 RESTConfiguration 元件中。對於 REST 服務的每個 HTTP 請求，RESTServiceServlet 元件將請求委託到 RESTActionController，它又會檢索相應的對映、驗證請求、建立ActionContext 元件以及路徑和查詢輸入，並呼叫 Action 類 （例如，createUserAction）。Action 類呼叫後端業務服務進行處理。