這篇文章，主要想總結自己在設計restful api的一系列經驗於思考。
有些規範可能與標準規範有所出入，但是所有的考量都是基於『減少重複工作，增加可讀性可維護性』而出發的。話說回來，我一直覺得 restful api 設計，確實沒有很明顯的公認規範（如果你是指發明者的那篇**，估計沒多少人詳細閱讀過，而且其作者只是提出了一系列概念而已）。網上的教程，似乎都是千篇一律的（我嚴重懷疑：都是 「借鑑or拷貝」 阮一峰老師的那幾篇文章），僵硬而且呆板，有點教條化（從來沒有人懷疑它們嗎，反正我按照這些教條設計api，沒有感受到多少樂趣）。
以上，並不是全部否定，好東西要充分吸收，不好的東西，要融合自己的理解，加以改造。
說到這個，似乎又要談及『restful 是對資源的抽象』、『結合了http 的特點』云云。不過這些都是一些沒用的套話，沒啥營養價值，而我想從另外的角度談論這個。
既然是 api，一般都符合 api 的一般模式：
resulttype apiname(paramtype )
1. 介面引數，即形參。可以是 string，int，以及其他任意可以稱之為引數的東西
2. 介面返回值。可以是 string，int，以及其他任意可以稱之為返回值的東西
3. 介面名（簽名)
複製**
1. httprequest：包括請求頭，url引數，請求body引數
2. httpresponse: 包括響應頭，響應的body
複製**這樣來看，restful api 無非是一種特殊的api 而已，通用的 api 設計法則，同樣適合 restful，只不過非變換形式而已。
那麼我們大概有哪些比較通用的標準呢？大概有這些：
介面命名，必須做到清晰。一般來說，做到『動賓短語』即可。
介面數量，越少越好。三個不如兩個，兩個不如乙個，乙個不如沒有，最好的 api 就是『沒有api』。
有明確的輸入輸出。念念不忘必有迴響，總是有返回值，告訴呼叫端，我到底做了什麼，做得怎麼樣，即：反饋。
下面就來看看這些標準，是如何影響下文的內容的，：）。
url 就是介面簽名，而簽名必須做到清晰，沒有歧義。
如果後端架構是服務化的，那麼有可能每個服務會對外提供公共的 restful api，那麼有個統一的字首格式，會比較好，比如：
/service_name/v1/users
or複製**
user -- 1：n --> server-- 1:n --> client ... 更加複雜的實體對映關係
1. /users//servers//clients
2. /clients
一般大家傾向於選項 1（但是實體關聯關係特複雜時，會縮短url），
不過選項2 也是乙個不錯的選擇，總而言之，口味問題吧。
複製**
獲取使用者列表資訊：get /users
獲取單個使用者資訊：get /users/
坦白說，獲取乙個與獲取一批，似乎並沒有什麼語義上的差別，
但是後端的同學就不一樣了，他可能需要寫兩個 view class。
所以只保留批量的介面，查詢乙個時，用 url 引數傳遞就行了。
複製**
put /users/
put /users
直接合併到乙個介面裡面做就行了，put 乙個 user與 put 一群 user，有啥本質的不同嗎？
複製**
delete /users/
刪除乙個user與刪除一批user，有啥不同？
如果要一次刪除100 個 user，難道讓前端同學，調 100 次這個介面？
多一次呼叫，就多一次風險（如網路問題），
這個時候就別守著 restful 那些個教條了，介面的可用性、效率性，更加重要。
這個時候，不如設計成這樣（至於 delete 介面能不能傳request body，這裡不討論）：
post /users_deletion
複製**
response headers
可以做少量文章，如自定義乙個header
status code
按照基本規範來，該404的404，該200的200
response body
基本都是圍繞這個做文章
複製**
}複製**
沒有很明確的規範，但是盡量跟隨資料庫的風格，即：下劃線風格。 這樣，在 序列化整個 model 時，也許會很方便。
參考 github 的風格。
基於JSON的RESTful介面協議
xml的格式可以改為json格式 對於restful api來講，我們已經解決了傳輸協議的問題 基於http，協議約定問題 基於json。最後要解決的是服務發現問題。有個著名的基於restful api 的跨系統呼叫框架叫spring cloud,在spring cloud中有乙個元件叫eureka...
基於Restful風格的API操作
索引操作 新增索引 put index 索引 查詢索引 get index 刪除索引 delete index 對映管理資料管理1.通過id查詢 語法1 通過id查詢所有 select get 索引名 型別 id 語法2 通過id查詢部分 select 欄位1,欄位2 get 索引號 型別 id?s...
基於MVC的RESTful風格的實現
紅塵 1.restful風格闡述 rest服務是一種roa resource oriented architecture,面向資源的架構 應用。主要特點是方法資訊存在於http協議的方法中 get,post,put,delete 作用域存在於url中。例如，在乙個獲取裝置資源列表的get請求中，方法...