RESTful風格接口并不適合所有情況
有時候，RESTful風格接口的確簡化了資源定位以及資源CRUD的問題，但是當我們想做一些特殊操作時 ,該風格顯然不適合。
RESTful風格接口組成
- 請求方法（
GET.POST,PUT,DELETE等） - 請求路徑 http://
ip:port/偽資源目錄/資源ID
問題
- 比如，我們在添加數(shù)據(jù)時，想對數(shù)據(jù)的某些特征值做唯一性判斷，這時，想創(chuàng)建一個RESTful風格的接口就發(fā)現(xiàn)很不適合
- 首先需要驗證的數(shù)據(jù)沒有資源ID，就無法定位服務器資源
- 該行為顯然是一種驗證操作，RESTful風格沒有相應的具體的請求方法
- 若請求方法為
POST,如果偽資源目錄后加入操作名，那就和資源ID沖突，感覺很不RESTful
- 當我們做多資源操作時，全拼在
偽資源目錄后面，要操作資源過多時，會造成url過長的問題，這種時候，把多個資源id放在body里面更為合適
解決方案
自定義接口標準
- 請求方法（
GET,POST） - 請求路徑http://
ip:port/偽資源目錄/操作/資源ID/資源屬性
梨子
- 域名：
www.baidu.com - 偽資源目錄：
user - 操作：
- 分頁查詢列表：
list - 添加：
add - 刪除：
delete,remove - 修改：
update,edit - 查詢詳情：
detail - 刪除多個：
remove-multiple,delete-multiple - 檢查唯一性：
check-unique
- 分頁查詢列表：
- 資源ID:
- 用戶名：
liuqi
- 用戶名：
- 資源屬性：
- 用戶名:
username - 密碼:
password - 郵件地址:
email - 電話:
phone
- 用戶名:
例如
- 獲取用戶信息詳情：GET +
http://www.baidu.com/user/detail/liuqi - 檢查用戶名唯一：POST +
http://www.baidu.com/user/check-unique - 只修改郵件地址：POST +
http://www.baidu.com/user/update/liuqi/email - 刪除多個用戶：POST +
http://www.baidu.com/user/update/liuqi/email
缺點
- 請求路徑比RESTful風格的要長
- 只使用了GET,POST方法
初次學習，多有不足，若有錯誤或者疑問，還請多多指教
