1、在接口定義中確定MVC的GET或者POST方式
由於我們整個WebAPI平臺是基於MVC的基礎上進行的API開發,因此整個WebAPI的接口,在定義的時候,壹般需要顯示來聲明接口是[HttpGet]或者[HttpPost],雖然有些接口也可以不用聲明,但是避免出現類似下面的錯誤信息,顯式聲明還是有好處的。
請求的資源不支持http方法“POST
例如在基類定義的查找對象接口如下所示。
///<summary>
///查詢數據庫,檢查是否存在指定ID的對象
///</summary>
///<paramname="id">對象的ID值</param>
///<returns>存在則返回指定的對象,否則返回Null</returns>
[HttpGet]
publicvirtualTFindByID(stringid,stringtoken)
如果是增刪改的接口,壹般需要聲明為POST方式提交數據,而且基於安全性的考慮,需要攜帶更多的參數。
///<summary>
///插入指定對象到數據庫中
///</summary>
///<paramname="info">指定的對象</param>
///<returns>執行操作是否成功。</returns>
[HttpPost]
publicvirtualCommonResultInsert(Tinfo,stringtoken,stringsignature,stringtimestamp,stringnonce,stringappid)
2、動態對象的接口定義
在壹般的WebAPI接口裏面,我們可能都會碰到很多簡單類型的參數,但是又想讓它們以POST方式提交數據,那麽我們就可以有兩種方法來處理,壹種是定義壹個類來放置這些參數,壹種是采用動態的JObject參數,前者有很多不方便的地方,因為我們不可能為每個接口參數定義多壹個實體類,這樣可能會有很多難以管理的類定義。如下面是微信API的調用接口案例,我們也需要設置這樣的處理規則。
接口調用請求說明
http請求方式:POST(請使用https協議)
POST數據格式:json
POST數據例子:{"group":{"id":108,"name":"test2_modify2"}}
那麽我們采用JObject是這麽樣的呢,我們來看接口的定義和處理代碼。JObject是命名空間下的壹個對象。
///<summary>
///修改用戶密碼
///</summary>
///<paramname="param">包含userName和userPassword的復合對象</param>
///<paramname="token">用戶訪問令牌</param>
///<returns></returns>
[HttpPost]
publicCommonResultModifyPassword(JObjectparam,stringtoken)
{
//令牌檢查,不通過則拋出異常
CheckResultcheckResult=CheckToken(token);
dynamicobj=param;
if(obj!=null)
{
stringuserName=;
stringuserPassword=;
boolsuccess=BLLFactory<User>.(userName,userPassword);
returnnewCommonResult(success);
}
else
{
thrownewMyApiException("傳遞參數出現錯誤");
}
}
其中我們把JObject對象轉換為我們所需要的對象的時候,因為我們沒有定義具體的實體類,因此采用了dynamic語法,聲明這是壹個動態對象,由運行時獲取對應的屬性。
dynamicobj=param;
這樣我們就可以在調用的時候,動態POST對應的JSON對象給WebAPI接口,而不需要預先定義各種接口參數的類了。
///<summary>
///調用WebAPI接口,修改用戶密碼
///</summary>
///<paramname="userName">用戶名稱</param>
///<paramname="userPassword">修改的密碼</param>
///<returns>如果修改成功返回true,否則返回false</returns>
publicboolModifyPassword(stringuserName,stringuserPassword)
{
varaction="ModifyPassword";
varpostData=new
{
userName=userName,
userPassword=userPassword
}.ToJson();
stringurl=GetTokenUrl(action);
CommonResultresult=JsonHelper<CommonResult>.ConvertJson(url,postData);
return(result!=null)?:false;
}
其中GetTokenUrl是根據token和API的地址等參數,構建壹個完整的提交地址。我們在上面代碼通過
varpostData=new
{
userName=userName,
userPassword=userPassword
}.ToJson();
就可以動態創建壹個對象,並生成它的JSON字符串,把數據POST提交到對應的API接口裏面即可,然後對結果進行對象的轉換就算完成了。
3、集合和分頁的處理
在很多接口裏面,我們都需要用到分頁的處理,WebAPI也不例外,這樣可以提交數據檢索效率,減少服務器數據處理的壓力,同時也提交客戶端的數據顯示速度。
壹般的集合接口定義如下所示(通用性基類接口)。
///<summary>
///返回數據庫所有的對象集合
///</summary>
///<returns>指定對象的集合</returns>
[HttpGet]
publicvirtualList<T>GetAll(stringtoken)
{
//檢查用戶是否有權限,否則拋出MyDenyAccessException異常
(,token);
List<T>list=();
returnlist;
}
但是這樣的返回記錄會比較多,壹般情況下需要分頁,那麽分頁的處理接口定義如下所示。
///<summary>
///根據條件查詢數據庫,並返回對象集合(用於分頁數據顯示)
///</summary>
///<returns>指定對象的集合</returns>
[HttpPost]
publicvirtualPagedList<T>FindWithPager(stringcondition,PagerInfopagerInfo,stringtoken)
分頁接口,在這裏返回的結果裏面,用了壹個PageList的泛型類,這個方便我們獲取當前的記錄及總數,它的定義如下所示。
///<summary>
///分頁集合
///</summary>
///<typeparamname="T">對象</typeparam>
publicclassPagedList<T>
{
///<summary>
///返回記錄的總數
///</summary>
publicinttotal_count{get;set;}
///<summary>
///列表集合
///</summary>
publicList<T>list{get;set;}
}
最後整個分頁的處理WebAPI接口實現如下所示。
///<summary>
///根據條件查詢數據庫,並返回對象集合(用於分頁數據顯示)
///</summary>
///<returns>指定對象的集合</returns>
[HttpPost]
publicvirtualPagedList<T>FindWithPager(stringcondition,PagerInfopagerInfo,stringtoken)
{
//檢查用戶是否有權限,否則拋出MyDenyAccessException異常
(,token);
List<T>list=(condition,pagerInfo);
//構造成Json的格式傳遞
varresult=newPagedList<T>(){total_count=,list=list};
returnresult;
}
最後客戶端調用分頁的WebAPI代碼如下所示。
///<summary>
///根據條件查詢數據庫,並返回對象集合(用於分頁數據顯示)
///</summary>
///<paramname="condition">查詢的條件</param>
///<paramname="pagerInfo">分頁實體</param>
///<returns>指定對象的集合</returns>
publicvirtualList<T>FindWithPager(stringcondition,refPagerInfopagerInfo)
{
varaction="FindWithPager";
stringurl=GetTokenUrl(action)+("&condition={0}",condition);
varpostData=();
List<T>result=newList<T>();
PagedList<T>list=JsonHelper<PagedList<T>>.ConvertJson(url,postData);
if(list!=null)
{
=_count;//修改總記錄數
result=;
}
returnresult;
}
4、混合框架界面整合WebAPI接口
在整個WebAPI的平臺構建以及在混合框架的整合過程中,我把各個模塊還是遵循相對獨立的方式進行開發和整合,它們實現了從直接訪問數據庫、以WCF服務獲取數據,以及通過WebAPI調用方式獲取數據幾種方式的統壹,從而實現了整個混合框架的高度整合。
整個混合框架的核心是以相對獨立的方式,整合各個可重用的模塊,我們可以遵循壹定的基礎上,快速構建統壹的應用平臺。
搭建完畢的整個WebAPI平臺,其中包括了服務端內容,以API控制器的方式,發布了對應的WebAPI接口。
在每個混合框架的獨立模塊裏面,我們封裝了對應的WebAPI客戶端調用處理,從而實現了WebAPI的調用方式。
在Win10下,使用WebAPI模式運行混合框架,獲得的主體界面效果如下所示。
獨立模塊權限管理系統界面如下所示。
系列文章如下所示:
WebAPI應用架構在Winform混合框架中的應用(1)
WebAPI應用架構在Winform混合框架中的應用(2)--自定義異常結果的處理
WebAPI接口設計經驗總結
WebAPI應用架構在Winform混合框架中的應用(3)--Winfrom界面調用WebAPI的過程分解
WebAPI應用架構在Winform混合框架中的應用(4)--利用代碼生成工具快速開發整套應用
WebAPI應用架構在Winform混合框架中的應用(5)--系統級別字典和公司級別字典並存的處理方式
如何設計API接口，請求接口時需要進行身份驗證，防止第三方隨意調用接口？接口使用方法:
1.接口調用者先申請分配壹個clientid,clientsecret,並提供給接口提供者(服務器)壹個可訪問的callbackURL(用於接口access_token)。
2.接口調用者使用clientid,clientsecret作為參數,向接口提供者發送請求。
接口提供者訪問callbackURL發送access_token(有時間限制,超時後重新獲取)。
3.接口調用者使用access_token作為參數,調用其他接口獲取相關信息。
4.接口調用者在access_token超時後重新獲取access_token。
有個疑問:
僅為了防止非法用戶隨意使用接口,需要這個復雜的機制嗎?
接口使用https連接,可以確保數據保密性。
所以是否可以簡化上面的流程,僅在接口服務者中配置壹個access_token,
接口使用者只需要提供正確的access_token即可正常使用其他接口。
如何正確合理的設計壹個接口項目了解原型,其實更多是為了幫助妳設計接口時需要提供的數據和結構。但有時當妳設計時並沒有原型,所以此條並不是必須要求的。但假如設計完接口後原型出來了,我們也可以拿原型還驗證接口設計是否正確、合理。