咱們設計的REST API真的nice么？
- 咱們設計的REST API真的nice么羹膳？
- 優(yōu)雅型：http://api.exapmle.com/louvre/da-vinci/mona-lisa
盧浮宮/達芬奇/蒙娜麗莎 - 中庸型：http://58.com/bj/ershou/310976
北京/二手頻道/帖子ID - 謝特型：http://api.example.com/68dd0-a9d3-11e0-9f1c
不知道什么鬼
URI設計的一些原則。
URI的末尾不要添加“/”
多一個斜杠脯燃，語義完全不同汤求，究竟是目錄旭绒，還是資源，還是不確定而多做一次301跳轉(zhuǎn)京痢？
負面case：http://api.canvas.com/shapes/
正面case：http://api.canvas.com/shapes使用“-”提高URI的可讀性
目的是使得URI便于理解奶甘，用“-”來連接單詞
正面case：http://api.example.com/blogs/my-first-post禁止在URL中使用“”
目的是提高可讀性，“”可能被文本查看器中的下劃線特效遮蔽
負面case：http://api.example.com/blogs/my_first_post
別爭历造，看到效果就明白了禁止使用大寫字母
RFC 3986中規(guī)定URI區(qū)分大小寫甩十，但別用大寫字母來為難程序員了，既不美觀吭产，又麻煩
負面case：http://api.example.com/My-Folder/My-Doc
正面case：http://api.example.com/my-folder/my-doc不要在URI中包含擴展名
應鼓勵REST API客戶端使用HTTP提供的格式選擇機制Accept request header
正面case：http://58.com/bj/ershou/310976
一個case：http://58.com/bj/ershou/310976x.shtml建議URI中的名稱使用復數(shù)
額侣监，樓主不知道為何會有這么奇怪的建議
正面case：http://api.college.com/students/3248234/courses
負面case：http://api.college.com/student/3248234/course
最后，給后端研發(fā)工程師一個建議：清晰優(yōu)雅的 RESTful API是為調(diào)用者編寫的臣淤，別無腦隨意定義一些shit一樣的URI給移動/前端工程師使用橄霉，小心生命有危險。
原文：http://blog.restcase.com/7-rules-for-rest-api-uri-design/
作者：Guy Levin
