restful 是目前最流行的 api 設計規範，用於 web 資料介面的設計
為了避免歧義，文件大量使用了「能願動詞」，對應的解釋如下：
api 的根入口點應盡可能保持足夠簡單，這裡有兩個常見的 url 根例子：
應該將 api 放到子域下（api.example.com）。這種做法可以保持某些規模化上的靈活性。
get /users/2 http/1.1必須在引入新版本 api 的同時確保舊版本 api 仍然可用。所以應該為其提供版本支援。
目前比較常見的兩種版本號形式：
http 請求動詞通常就是五種方法，對應 crud 操作。
針對每乙個端點來說，下面列出所有可行的http動詞和端點的組合
請求方法
url描述
get/zoos
列出所有的動物園(id和名稱，不要太詳細)
post
/zoos
新增乙個新的動物園
get/zoos/
獲取指定動物園詳情
put/zoos/
更新指定動物園(整個物件)
patch
/zoos/
更新動物園(部分物件)
delete
/zoos/
刪除指定動物園
get/zoos//animals
檢索指定動物園下的動物列表(id和名稱，不要太詳細)
get/animals
列出所有動物(id和名稱)。
post
/animals
新增新的動物
get/animals/
獲取指定的動物詳情
put/animals/
更新指定的動物(整個物件)
patch
/animals/
更新指定的動物(部分物件)
get/animal_types
獲取所有動物型別(id和名稱，不要太詳細)
get/animal_types/
獲取指定的動物型別詳情
get/employees
檢索整個雇員列表
get/employees/
檢索指定特定的員工
get/zoos//employees
檢索在這個動物園工作的雇員的名單(身份證和姓名)
post
/employees
新增指定新員工
post
/zoos//employees
在特定的動物園僱傭一名員工
delete
/zoos//employees/
從某個動物園解雇一名員工
超出restful端點的，應該模仿上表的方式來定義端點。
如果記錄數量很多，伺服器不可能都將它們返回給使用者。api應該提供引數，過濾返回結果。下面是一些常見的引數。所有url引數必須是全小寫，必須使用下劃線型別的引數形式。
分頁引數經常使用的、複雜的查詢必須固定為page、per_page
應該標籤化，降低維護成本。如
get /trades?status=closed&sort=sortby=name&order=asc對建立新資源的 post 操作進行響應。應該帶著指向新資源位址的 location 頭伺服器接受了請求，但是還未處理，響應中應該包含相應的指示資訊，告訴客戶端該去**查詢關於本次請求的資訊對不會返回響應體的成功請求進行響應（比如 delete 請求）請求異常，比如請求中的body無法解析沒有進行認證或者認證非法或失效伺服器已經理解請求，但是拒絕執行它都必須返回該狀態碼，若該資源已永久不存在，則應該返回410響應。
所請求的 http 方法不允許當前認證使用者訪問
該狀態碼表示因為請求存在衝突無法處理。
如通過手機號碼提供註冊功能的 api，當使用者提交的手機號已存在時，必須 返回此狀態碼。
表示當前請求的資源已永久不存在。當呼叫老版本 api 的時候很有用
該狀態碼表示伺服器拒絕處理當前請求，因為該請求提交的實體資料大小超過了伺服器願意或者能夠處理的範圍。
此種情況下，伺服器可以關閉連線以免客戶端繼續傳送此請求。如果這個狀況是臨時的，伺服器
應該返回乙個retry-after的響應頭，以告知客戶端可以在多少時間以後重新嘗試。
該狀態碼表示請求的uri長度超過了伺服器能夠解釋的長度，因此伺服器拒絕對該請求提供服務。
通常表示伺服器不支援客戶端請求首部content-type指定的資料格式。如在只接受json格式的api中放入xml型別的資料並向伺服器傳送，都應該返回該狀態碼。
用來表示校驗錯誤,
"status_code": 422
}
api設定為60次/分鐘，當使用者在一分鐘內請求次數超過 60 次後，都應該返回該狀態碼。並且也應該在響應首部中加上下列頭部：
x-ratelimit-limit: 10 請求速率（由應用設定，其單位一般為小時/分鐘等，這裡是 10次/5分鐘）
x-ratelimit-remaining: 0 當前剩餘的請求數量
x-ratelimit-reset: 1529839462 重置時間
retry-after: 120 下一次訪問應該等待的時間（秒）
必須為所有的 api 設定 rate limit 支援。
對於錯誤資料，預設使用如下結構：
'message' => ':message', // 錯誤的具體描述
'errors' => ':errors', // 引數的具體錯誤描述，422 等狀態提供
'code' => ':code', // 業務自定義的異常碼
'status_code' => ':status_code', // http狀態碼
'debug' => ':debug', // debug 資訊，非生產環境提供
http/1.1 422 unprocessable entity
UI設計規範
以使用者為中心。設計由使用者控制的介面，而不是介面控制使用者。清楚一致的設計。所有介面的風格保持一致，所有具有相同含義的術語保持一致，且易於理解 較快的響應速度。簡單且美觀。使用者介面設計的乙個重要原則是使用者應該總是感覺在控制軟體而不是感覺被軟體所控制。操作上假設是使用者 而不是計算機或軟體 開始...
硬體設計規範
1 硬體需求說明書 2 硬體總體設計報告 3 單板硬體總體設計方案 4 單板硬體詳細設計 5 單板硬體過程除錯文件 6 單板硬體系統除錯報告 7 單板硬體測試文件 8 硬體總體方案歸檔詳細文件 9 硬體單板總體方案歸檔詳細文件 10 硬體資訊庫 2.2.2 硬體開發文件編制規範詳解 1 硬體需求說明...
Mysql設計規範
資料庫命名規範 1 所有資料庫物件名稱必須使用小寫字母並用下劃線分割。2 所有資料庫物件名稱禁止使用mysql保留關鍵字 3 資料庫物件的命名要能做到見名識義，並且最好不要超過32個字元。4 臨時表必須以tmp為字首並以日期為字尾。5 備份庫，備份表必須以bak為字首並以日期為字尾。6 所有儲存相同...