咱們設計的rest api真的nice麼？
優雅型：
羅浮宮/達文西/蒙娜麗莎
中庸型：
北京/二手頻道/帖子id
謝特型：
不知道什麼鬼
本文將分享uri設計的一些原則。
1. uri的末尾不要新增「/」
多乙個斜槓，語義完全不同，究竟是目錄，還是資源，還是不確定而多做一次301跳轉？
負面case：
正面case：
2. 使用「-」提高uri的可讀性
目的是使得uri便於理解，用「-」來連線單詞
正面case：
3. 禁止在url中使用「_」
目的是提高可讀性，「_」可能被文字檢視器中的下劃線特效遮蔽
負面case：
別爭，看到效果就明白了
4. 禁止使用大寫字母
rfc 3986中規定uri區分大小寫，但別用大寫字母來為難程式設計師了，既不美觀，又麻煩
負面case：
正面case：
5. 不要在uri中包含副檔名
應鼓勵rest api客戶端使用http提供的格式選擇機制accept request header
正面case：
乙個case：x.shtml
6. 建議uri中的名稱使用複數
額，樓主不知道為何會有這麼奇怪的建議
正面case：
負面case：
最後，給後端研發工程師乙個建議：清晰優雅的 restfulapi是為呼叫者編寫的，別無腦隨意定義一些****一樣的uri給移動/前端工程師使用，小心生命有危險。
原文：
你見過一些什麼奇葩的uri？
URI設計原則
咱們設計的rest api真的nice麼？優雅型 羅浮宮 達文西 蒙娜麗莎 中庸型 北京 二手頻道 帖子id 謝特型 不知道什麼鬼 本文將分享uri設計的一些原則。1.uri的末尾不要新增 多乙個斜槓，語義完全不同，究竟是目錄，還是資源，還是不確定而多做一次301跳轉？負面case 正面case 2...
架構篇 URI設計原則
author simon 優雅型 羅浮宮 達文西 蒙娜麗莎 中庸型 北京 新聞頻道 新聞id 謝特型 斜槓分隔符 必須用於顯示層次關係正例 反例 使用 提高uri的可讀性正例 禁止在url中使用 目的是提高可讀性，可能被文字檢視器中的下劃線特效遮蔽 反例 禁止使用大寫字母rfc 3986中規定uri...
服務API設計 之 API設計原則
對接xx業務時，xx業務具備的功能和api全靠跑業務負責人那反覆逐個詢問 確認。用哪個api 怎麼用 有沒有限制 等等 各個業務間，甚至同一業務內，api風格不統一。xx業務api效能方面未知。隨著業務的演進，開放的api持續在增加，但類同的很多 api編碼規範迫在眉睫 自解釋 易學習 易使用 難誤...