Web API 是一種應用接口架構，它能夠建構HTTP服務以支撐更廣泛的用戶端（包括浏覽器，手機和平闆電腦等移動裝置）的架構， ASP.NET Web API 是一種用于在 .NET Framework 上建構 RESTful 應用程式的理想平台。在目前發達的應用場景下，我們往往需要接入Winform用戶端、APP程式、網站程式、以及目前熱火朝天的微信應用等，這些資料應該可以由同一個服務提供，這個就是我們所需要建構的Web API平台。由于Web API層作為一個公共的接口層，我們就很好保證了各個界面應用層的資料一緻性。
通過上面的了解，我們可以知道，所有外部的應用，其實都可以基于一個相同的Web API核心開展的，如下圖所示。
在目前大平台，大應用的背景下，可以基于一個整體的平台，建構很多應用生态鍊，這樣就可以把Web API作為核心層，可以在上面開發我們各種企業業務應用了。
在Winform界面裡面，我們除了可以利用直接通路資料庫方式，以及采用通路分布式WCF服務的方式接入，還可以使得它能夠通路Web API的資料服務，進而建構成一個适應性更加廣泛、功能更加強大的混合式開發架構模式；對于Web API，由于它提供的是一種無狀态的接口通路，而且往往Web API一般為了多種用戶端接入的需要，可能需要釋出在公網上進行通路，是以我們需要更加注重Web API接口層的安全性。
除了直連資料庫通路的傳統模式，WCF分布式通路的WCF服務通路模式，還可以接入API分布式通路的Web API接口模式，他們的關系構成了一個完整的Winform應用體系，如下圖所示。
混合式架構的實作細節，就是通過一個類似開關模式的配置子產品，确定是采用直接通路資料庫方式，還是通路WCF服務的方式，它們兩者是統一到一個Facade接口門面層上，如果考慮到Web API層，基于混合式的架構，也就是在這個Facade接口門面層上增加多一個Web API的接口的封裝成即可。具體整個架構的架構圖如下所示。
Web API接口的通路方式，大概可以分為幾類：
1）一個是使用使用者令牌，通過Web API接口進行資料通路。這種方式，可以有效識别使用者的身份，為使用者接口傳回使用者相關的資料，如包括使用者資訊維護、密碼修改、或者使用者聯系人等與使用者身份相關的資料。
2）一種是使用安全簽名進行資料送出。這種方式送出的資料，URL連接配接的簽名參數是經過安全一定規則的加密的，伺服器收到資料後也經過同樣規則的安全加密，确認資料沒有被中途篡改後，再進行資料修改處理。是以我們可以為不同接入方式，如Web/APP/Winfrom等不同接入方式指定不同的加密秘鑰，但是秘鑰是雙方約定的，并不在網絡連接配接上傳輸，連接配接傳輸的一般是這個接入的AppID，伺服器通過這個AppID來進行簽名參數的加密對比，這種方式，類似微信背景的回調處理機制，它們就是經過這樣的處理。
3）一種方式是提供公開的接口調用，不需要傳入使用者令牌、或者對參數進行加密簽名的，這種接口一般較少，隻是提供一些很正常的資料顯示而已。
基于上面的考慮，我們一般需要設計Web API對象的接口的時候，需要考慮安全性的原因，也就是需要增加更多的一些字段資訊了。
如可以在增删改這些接口，除了傳入token資訊外（辨別具體使用者），也還是需要傳入簽名資訊，如下接口所示。
上面接口，除了info對象為對象建立的參數外，其他幾個參數，都是為了安全性的考慮而加入的。
在接口裡面，我們就需要對使用者的權限和簽名資訊進行校驗，然後在進行下一步的資料處理，如果校驗權限和參數完整性不通過，則會被攔截，不執行資料庫的處理了。
除了這些對資料修改的特殊性接口，有時候我們還需要查找等類似的，不對資料産生變化的接口，隻需要傳入令牌即可，如下接口所示。
我們可以看到，上面還是會對token進行校驗，不過少了很多簽名所需的日期辨別、随機數，完整性校驗簽名，應用ID等參數。
我們會根據使用者的token進行解析，如果是正常的token并可以通過解析，那麼擷取對應使用者的權限，判斷是否可以進行下一步處理即可。
如果順利通過，那麼通路資料庫，把所需的資料傳回給調用者即可。
上面提到了使用者令牌，使用者令牌是一個類似實際生活的通行證，是通過使用者名、密碼等資訊擷取到的一個安全令牌，可以在多個接口進行傳遞的字元串，較少密碼參數的傳輸，提高安全性。
這個使用者令牌，一般由單獨的接口産生，我們一般放到AuthController裡面，這個控制器負責使用者令牌相關的處理調用。
如下代碼是具體業務子產品裡面，說明如何擷取用于操作各種接口的token令牌的，當然，實際環境下，一般都會使用HTTPS協定擷取資料了，示範代碼如下所示。
由于Web API的調用，都是一種無狀态方式的調用方式，我們通過token來傳遞我們的使用者資訊，這樣我們隻需要驗證Token就可以了。JWT的令牌生成邏輯如下所示
令牌生成後，我們需要在Web API調用處理前，對令牌進行校驗，確定令牌是正确有效的。
除了令牌的規則，還有一個是加密簽名的處理，加密簽名需要用戶端和伺服器端約定相同的秘鑰，一般由Web API統一配置設定，然後傳輸的時候，用戶端使用應用ID即可。
加密簽名在服務端（Web API端）的驗證流程參考微信的接口的處理方式，處理邏輯如下所示。
1）檢查timestamp 與系統時間是否相差在合理時間内，如10分鐘。
2）将appSecret、timestamp、nonce三個參數進行字典序排序
3）将三個參數字元串拼接成一個字元串進行SHA1加密
4）加密後的字元串可與signature對比，若比對則辨別該次請求來源于某應用端，請求是合法的。
上面介紹了一些Web API控制器的職能，一般情況下，我們設計一個架構，還需要考慮到基類對象之間的重用關系，盡可能把接口抽象到基類層面上去，減少子類的開發代碼量，降低維護成本。
基于上面的目的，參考了我的Web開發架構對于MVC控制器的設計思路
重新整理了Web API的控制器設計對象繼承關系，如下所示：
我們關鍵的核心就是設計好BusinessController<B, T>這個基類，裡面設計了大量的通用接口，包括正常的增删改查、分頁等處理接口，那麼子類繼承過來就可以直接擁有這些接口了，多友善啊。
上面介紹了Web API服務端平台的架構設計思路，通過上面的整合，我們減輕了開發重複功能的增删改查等基礎功能的控制器代碼，把這些接口抽象到接口裡面即可實作。
但是我們具體應該如何遵循統一接口層Facade層的約定，然後統一調用WebAPI層的接口，做到悄無聲息的從不同的資料源裡面擷取資料，展示在用戶端裡面呢。
上面我們分析到，整個混合式Winform架構子產品裡面，設計方面考慮了資料的擷取方面：包含了直接從資料庫擷取，從WCF服務擷取，以及Web API層的資料擷取三部分内容，當然還可以有更多的資料Access模式（如WebService等），設計效果如下所示。
所有的資料接入，我們在Facade層都統一到接口裡面，用戶端的調用也統一到了CallerFactory<T>這個泛型工廠裡面，我們根據配置的不同，從不同的子產品裡面加載，進而實作不同資料源的動态擷取了。
如下邏輯就是CallerFactory<T>泛型工廠類的加載邏輯，如下所示：
為了實作簡化用戶端調用的封裝，我們一般也把正常的通用操作封裝一下，如下是我原先混合架構裡面的設計思路，裡面的封裝都是通過***Caller的類來進行資料的通路的，這些類統一實作一定關系的內建封裝。
為了簡化說明調用接口的處理，這裡把上面的關系進行了簡化，并加入了Web API的調用封裝類的處理，幾種通路模式下的調用端封裝繼承關系，如下設計圖所示。
最底層的幾個DictDataCaller分别是不同通路方式下的接口調用封裝類，對于Web API來說，它的通路代碼就是如下所示。
第一個Delete函數是基類提供的，這裡進行了重寫，一般情況下，不需要處理就具備增删改分頁等基礎接口的調用封裝了。
由于所有的實作類都實作繼承了統一的Facade層的接口，那麼統一調用也就是自然而然的事情了。是以在Winform界面裡面，所有的調用都是使用CallerFactory<T>進行了統一的處理，資料通路的不同不影響接口的處理， 三種方式的資料調用，統一都是下面的代碼進行處理。
系列文章如下所示：
<a href="http://www.cnblogs.com/wuhuacong/p/4838220.html">Web API應用架構在Winform混合架構中的應用（1）</a>
<a href="http://www.cnblogs.com/wuhuacong/p/4843422.html">Web API應用架構在Winform混合架構中的應用（2）--自定義異常結果的處理</a>
<a href="http://www.cnblogs.com/wuhuacong/p/4902950.html">Web API應用架構在Winform混合架構中的應用（3）--Winfrom界面調用WebAPI的過程分解</a>
<a href="http://www.cnblogs.com/wuhuacong/p/4910240.html">Web API應用架構在Winform混合架構中的應用（4）--利用代碼生成工具快速開發整套應用</a>
<a href="http://www.cnblogs.com/wuhuacong/p/4915935.html">Web API應用架構在Winform混合架構中的應用（5）--系統級别字典和公司級别字典并存的處理方式</a>