REST之前的重要協議SOAP rest(簡單理解風格、約束、設計理念) rest之前是SOAP:SOAP Web API采用RPC風格，它采用面向功能的架構，所以我們在設計SOAP Web API的時候首相考慮的是應高提供怎樣的功能（或者操作）。RESTful Web API采用面向資源的架構，所以在設計之初首先需要考慮的是有哪些資源可供操作 SOAP通常以xml描述數據而rest提倡json描述數據（xml和json都是通用格式的與語言無關，可以在不同的語言中互通） RESTFul API基于REST 的api設計理念? （輕，通常用json描述數據,無狀態） 基于資源，增刪改查只是對于資源狀態的改變 使用http動詞（GET:查詢、POST：創建、PUT：更新、DELETE:刪除）來操作資源?? 查詢get：/movie/:mid? ? ?不符合rest規范的：/getmovie/:mid >tp5.0支持`RESTFul` 對每個http請求的響應結果都指明一個特別的狀態碼（200、201、202、400、401、403、404、500、...） 如：403：當A用戶請求了B用戶的id號那么判斷越權返回403 錯誤碼：自定義的錯誤id號 統一描述錯誤：錯誤碼、錯誤信息、當前url 使用Token令牌來授權和驗證身份（這里不用cookie） 版本控制 測試與生產環境分開：api/xxx.com? dev.api.xxx.com url語義要明確，最好可以望文知義 最好有一份比較標準的文檔 參考豆瓣開放API 和github開發者API 不要盲目照搬rest標準哦 接口安全、接口認證、接口性能、接口控流、接口緩存設計（緩存過期策略、緩存命中、緩存優化） 可能問題： ? 接口請求地址和參數暴露 ? 重要接口返回的數據明文暴露 ? app登錄態請求的數據安全性問題 ? 代碼層的數據安全問題? 解決辦法： ? 基本參數放入header ? 每次http請求都攜帶 授權碼sign ? 授權碼sign 有效性(客戶端攜帶時間與數據一起生成sign，訪問服務端時解密sign的時間) ? 授權碼sign唯一性保證（存入mysql、文件、redis） ? 請求參數、返回數據 按照安全性適當加密 （加密方式：md5 AES(推薦)? RSA） ? access\_token