前言
經過前2節的介紹，我們已經把資料通路層搭建好了，從本章開始就是Web Api部分了。在正式開始之前，再一次回顧一下Web Api的應用場景：Web Api可以與 MVC,WebForm結合使用，也可以作為一個單獨的Web服務。在正式讨論Web Api的配置以及如何構造我們的URI來消費資源之前，我們必須了解Http方法與我們将要通路的資源之間的關系。舉個簡單的例子，我們把模型”Course”作為我們通路的資源，下面就列舉了通路這個資源的http方法：
Action
HTTP Verb
Relative URI
擷取所有課程資訊
GET
/api/courses
根據某個Id擷取單個課程
/api/courses/id
新增一個課程
POST
/api/coursesNew course is sent in POST body
更新一個課程
PUT or PATCH
/api/courses/idUpdated course is sent in POST body
删除一個課程
DELETE
第一步：建立Web Api項目
右擊解決方案->添加建立項目
下一步：
點選确定
第二步：配置第一個路由
在建立好項目之後，我們可以在App_Start檔案夾下看到“WebApiConfig”類。這個類就是用來配置路由資訊的，這個類最終會在“Global.asax”的Application_Start()方法中被調用，後面我們會在這個這個類裡面配置多條路由資訊。
配置第一個路由：
分析一下上面這段代碼：我們建立了一個Courses的路由規則，這個路由模闆會比對到“api/courses/{id}”的URI，在這個模闆定義了2個預設值（api,courses）以及一個可選值（id）。對于“/api/courses or /api/courses/5”URI就會被我們的路由模闆比對到，同時“/api/courses”URI也會被比對到，因為Id是可選的。
第三步：添加第一個控制器（courses controller）
Web Api中的Controller是用來處理用戶端Http請求的（與MVC中的Controller類似），首先，建立Controller——右擊Controller檔案夾->建立項->控制器
然後出現下面視窗：
選擇Web API 2控制器-空，并命名為CoursesController。然後确定
打開剛才建立的Controller,可以看到我們建立的類繼承自“ApiController”。同時對于這個類的類名必須是“CoursesController”，因為在Web Api中預設的控制器選擇方式是尋找所有繼承自“ApiController”類并且這個類是以“Courses”開頭（這是在我們的路由規則中配置的）的控制器。
第四步：在Controller中添加Action
首先，我們建立上述表格列舉到的前2個方法（GetAllCourses，GetCourseById）
方法的選擇是智能的，如果我們建立了2個方法Get()和GetCourse(int id),假設我們發送一個GET請求并且URI是“/api/courses/5”，那麼“GetCourse(int id)”方法就會被選擇執行，這是因為方法是以Get開頭而且URI中包含Id的值。這種選擇方式同樣适用以其他的Http方法（put，delete，post），下面上代碼：
總結
到目前為止我們已經讓Web Api跑起來了，但仍然有很多不足之處：
傳回對象時出現循環依賴，可以通過模型工廠模式解決。
我們傳回了領域模型中所有的字段給用戶端，然而有一些敏感資訊不應該傳回（例如：password字段），解決方案：模型工廠模式
每一個傳回給用戶端的資源都應該包含一個URI以便用戶端查詢，解決方案依舊是模型工廠模式。
對于傳回單個資源，我們應當傳回相應的狀态碼（例如：成功200，資源未找到404等），解決方案：HttpResponseMessage對象
在每個方法裡我們都執行個體化了一個repository，這個對象包含了一些昂貴的操作（例如：資料庫連接配接），解決方案：依賴注入模式
對于傳回的Json對象格式是以“帕斯卡”風格的（例如“FirstName”），然而我們的Api有很大的可能被帶有Javascript的用戶端消費，對于JS開發者來說可能更适合“駝峰”風格（例如”firstName”）的資料。解決方案：配置Json格式。
ok，下一章我們就着重解決上述的問題