restful介面設計原則/最佳實踐（學習筆記）
1、restful介面建議統一使用複數，而不是單數
2、不建議使用hateoas
3、在大多數的教案中，都推薦使用accept header來指明是xml還是son，而作者建議直接在url中增加.json或者.xml
4、使用snake_case命名風格來給restful url命名，而不是camelcase風格
5、為了保證介面的可讀性和友好性，不建議自己將json中多餘的空白去除，而是提供格式化良好的資訊以滿足使用者除錯的需求，啟用gzip同樣能夠減少到因為空白等問題而引起的資料大小問題。
6、當乙個resource被查詢的時候，可能有一些相關的資源需要被關聯出來，則可以在引數中攜帶embed (或者expand），然後可以把相關的資源展開（比如原來描述乙個id，現在把id對應的具體物件也查詢出來）。
7、原文中一些其它的觀點（非常多），因為比較常見/不太容易簡單地表述，所以就沒有列出來了，最好閱讀原文。
個人理解：（非原文觀點）
1、關於embed（或者expand）引數而言，如果是用文件式/keyvalue式的nosql資料庫，則似乎根本不需要，它們本身就把物件聚合在了一起。
2、關於快取，如果要在restful中用好etag、last-modified，假設restful後台是關係型資料庫，那麼如何標識乙個資源的版本/修改時間呢？這個其實是非常難的，因為對於乙個存在多表聯查的物件而言，你可以保證單個表中的資訊未更改，你不能保證關聯表中的資訊未更改，而且當你再增加fields（參考原文）限定的時候，你說在此範圍之外的變化算變化還是不算變化？但是用文件式/keyvalue式的nosql資料庫的話，感覺在大部分場景上就容易得多，因為通常乙個key對應的結果，是固定的，不存在多表聯查的問題，那麼版本號這件事就可以是乙個特殊值被「設計」在物件中。
Restful介面設計
rest是英文representational state transfer 表象性狀態轉變 或者表述性狀態轉移 rest是web服務的一種架構風格 使用http,uri,xml,json,html等廣泛流行的標準和協議 輕量級,跨平台,跨語言的架構設計 它是一種設計風格,不是一種標準,是一種思想 ...
介面設計原則
在概要設計階段，根據需求階段的調研結果，我整理了系統介面設計的基本原則。因為在 開發階段，很多時候介面的具體製作室由開發人員直接寫 因此必須確定一定的原則和規範，以保證系統介面的統一。一般適用原則 b s架構使用原則 螢幕適應 web頁面需要適應不同使用者螢幕大小。瀏覽器相容 需要適應不同瀏覽效果，...
RESTFUL介面設計規範
rest 是representational state transfer的縮寫，意思是表述性狀態轉移，我個人理解就是資源資料的變化。api與使用者的通訊協議，總是使用https協議。協議網域名稱 應該盡量將api部署在專用網域名稱之下。如果確定api很簡單，不會有進一步擴充套件，可以考慮放在主網域...