前言

經過前2節的介紹，我們已經把資料訪問層搭建好了，從本章開始就是Web Api部分了。在正式開始之前，再一次回顧一下Web Api的應用場景：Web Api可以與 MVC,WebForm結合使用，也可以作為一個單獨的Web服務。在正式討論Web Api的配置以及如何構造我們的URI來消費資源之前，我們必須理解Http方法與我們將要訪問的資源之間的關係。舉個簡單的例子，我們把模型”Course”作為我們訪問的資源，下面就列舉了訪問這個資源的http方法：

第一步：建立Web Api專案

右擊解決方案->新增新建專案

下一步：

點選確定

第二步：配置第一個路由

在建立好專案之後，我們可以在App_Start資料夾下看到“WebApiConfig”類。這個類就是用來配置路由資訊的，這個類最終會在“Global.asax”的Application_Start()方法中被呼叫，後面我們會在這個這個類裡面配置多條路由資訊。

配置第一個路由：

config.Routes.MapHttpRoute(
                name: "Courses",
                routeTemplate: "api/courses/{id}",
                defaults: new {controller="courses", id = RouteParameter.Optional }
            );

分析一下上面這段程式碼：我們建立了一個Courses的路由規則，這個路由模板會匹配到“api/courses/{id}”的URI，在這個模板定義了2個預設值（api,courses）以及一個可選值（id）。對於“/api/courses

第三步：新增第一個控制器（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），下面上程式碼：

public class CoursesController : ApiController
    {
        public List<Course> Get()
        {
            ILearningRepository repository = new LearningRepository(new LearningContext());
 
            return repository.GetAllCourses().ToList();
        }
 
        public Course GetCourse(int id)
        {
            ILearningRepository repository = new LearningRepository(new LearningContext());
 
            return repository.GetCourse(id);
        }
     }

當我們建立一個Get請求並且URI是“http://localhost:{your_port}/api/courses”時候，Get（）方法會被選擇呼叫，下面是相應的部分程式碼:

[
    {
        "Id": 1,
        "Name": "History Teaching Methods 1",
        "Duration": 3,
        "Description": "The course will talk in depth about: History Teaching Methods 1",
        "CourseTutor": {
            "Courses": [],
            "Id": 1,
            "Email": "[email protected]",
            "UserName": "AhmadJoudeh",
            "Password": "SWDQNPSE",
            "FirstName": "Ahmad",
            "LastName": "Joudeh",
            "Gender": 0
        },
        "CourseSubject": {
            "Courses": [],
            "Id": 1,
            "Name": "History"
        },
        "Enrollments": []
    },
    {
        "Id": 2,
        "Name": "History Teaching Methods 2",
        "Duration": 3,
        "Description": "The course will talk in depth about: History Teaching Methods 2",
        "CourseTutor": {
            "Courses": [],
            "Id": 1,
            "Email": "[email protected]",
            "UserName": "AhmadJoudeh",
            "Password": "SWDQNPSE",
            "FirstName": "Ahmad",
            "LastName": "Joudeh",
            "Gender": 0
        },
        "CourseSubject": {
            "Courses": [],
            "Id": 1,
            "Name": "History"
        },
        "Enrollments": []
    },

如果你傳送一個Get請求並且URI是“http://localhost:{your_port}/api/courses/5”。那麼GetCourse(int id)將會被選擇呼叫執行。但是很遺憾在呼叫這個方法之後就會產生一個異常，這個異常資訊簡單來說就是“序列化物件的時候出現了迴圈依賴”，換句話說就是物件間迴圈引用（Course>Enrollment>Course>Enrollment>etc…）

總結

到目前為止我們已經讓Web Api跑起來了，但仍然有很多不足之處：

   返回物件時出現迴圈依賴，可以通過模型工廠模式解決。

   我們返回了領域模型中所有的欄位給客戶端，然而有一些敏感資訊不應該返回（例如：password欄位），解決方案：模型工廠模式

   每一個返回給客戶端的資源都應該包含一個URI以便客戶端查詢，解決方案依舊是模型工廠模式。

   對於返回單個資源，我們應當返回相應的狀態碼（例如：成功200，資源未找到404等），解決方案：HttpResponseMessage物件

  在每個方法裡我們都例項化了一個repository，這個物件包含了一些昂貴的操作（例如：資料庫連線），解決方案：依賴注入模式

  對於返回的Json物件格式是以“帕斯卡”風格的（例如“FirstName”），然而我們的Api有很大的可能被帶有Javascript的客戶端消費，對於JS開發者來說可能更適合“駝峰”風格（例如”firstName”）的資料。解決方案：配置Json格式。

ok，下一章我們就著重解決上述的問題