RESTful接口設計原則/最佳實踐（學習筆記）

RESTful接口設計原則/最佳實踐（學習筆記）

原文地址：http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

一、RESTful接口建議統一使用複數，而不是單數
二、不建議使用HATEOAS
三、在大多數的教案中，都推薦使用Accept Header來指明是xml仍是son，而做者建議直接在url中增長.json或者.xml
四、使用snake_case命名風格來給RESTful URL命名，而不是camelCase風格
五、爲了保證接口的可讀性和友好性，不建議本身將json中多餘的空白去除，而是提供格式化良好的信息以知足用戶調試的需求，啓用gzip一樣可以減小到由於空白等問題而引發的數據大小問題。
六、當一個Resource被查詢的時候，可能有一些相關的資源須要被關聯出來，則能夠在參數中攜帶embed (或者expand），而後能夠把相關的資源展開（好比原來描述一個id，如今把id對應的具體對象也查詢出來）。
七、原文中一些其它的觀點（很是多），由於比較常見/不太容易簡單地表述，因此就沒有列出來了，最好閱讀原文。

 

我的理解：（非原文觀點）

一、關於embed（或者expand）參數而言，若是是用文檔式/KeyValue式的NoSQL數據庫，則彷佛根本不須要，它們自己就把對象聚合在了一塊兒。
二、關於緩存，若是要在RESTful中用好ETag、Last-Modified，假設RESTful後臺是關係型數據庫，那麼如何標識一個資源的版本/修改時間呢？這個實際上是很是難的，由於對於一個存在多表聯查的對象而言，你能夠保證單個表中的信息未更改，你不能保證關聯表中的信息未更改，並且當你再增長fields（參考原文）限定的時候，你說在此範圍以外的變化算變化仍是不算變化？可是用文檔式/KeyValue式的NoSQL數據庫的話，感受在大部分場景上就容易得多，由於一般一個Key對應的結果，是固定的，不存在多表聯查的問題，那麼版本號這件事就能夠是一個特殊值被「設計」在對象中。