本文所需的一些預備知識可以看這裡: http://www.cnblogs.com/cgzl/p/9010978.html 和 http://www.cnblogs.com/cgzl/p/9019314.html

本文介紹的是使用ASP.NET Core建立Richardson成熟度為2級的偽RESTful web API, 本文介紹的是GET和POST.

使用的項目是(右鍵另存為, 然後把尾碼名改為zip): https://images2018.cnblogs.com/blog/986268/201805/986268-20180516191053536-1701412182.jpg

RESTful API 資源 (Resource) 的命名指導規範

首先, 資源應該使用名詞, 它是個東西, 不是動作.

例如:

• api/getusers 就是不正確的.
• GET api/users 就是正確的
• GET api/users/{userId}.

所以資源應該使用的是名詞.

如果是非分層結構的資源, 那麼它不應該這樣命名: api/xxx/xxx/users, 而應該使用 api/users.

如果是單個資源, 不應該這樣 api/id/users, 而應該是 api/users/{userId}.

(資源名是否複數還是根據個人習慣吧).

命名應該可以體現資源的結構

例如 api/department/{departmentId}/emoloyees, 這就表示了department (部門)和 員工(employee)之前是主從關係.

而 api/department/{departmentId}/emoloyees/{employeeId}, 就表示了該部門下的某個員工.

而過濾, 排序等不是資源, 所以這樣寫 api/users/orderby/username 是不正確的.

過濾排序這類的參數是可以作為查詢參數傳遞進來的, 正確的寫法應該是: api/users?orderby=username.

但是有時候, RPC風格的方法調用很難映射成規範的資源命名, 所以有時可以打破規範 例如 api/users/{userId}/totalsalaries.

應該使用什麼類型作為ID

如果使用int型作為ID的話, 大部分時候是沒有問題的, 但是如果您使用的資料庫的ID是自增整型的, 如果你替換資料庫了, 然後把原有數據遷移到新資料庫了, 那麼現有數據的ID就會發生變化, 那麼相當於所有的資源的地址發生了變化, 這就違反了這個:

資源的URI應該永遠都是一樣的.

所以GUID應該作為ID來使用. (但是我為了省事, 還是使用自增int作為ID吧