Web服務端開發需要考慮的問題

API設計

1. 是否Restful。

   首先需要清楚，Restful是一種風格而不是規範，不存在必須遵守的問題。
   Restful本質上是對HTTP API進行有效的分類。

   分類是應該的，可以讓API組織變得有序、層次清晰

2. 一定要以Restful的風格分類嗎？

   Restful風格的特點

   • url表示的只是資源，沒有動作，所以只會出現名詞，不會出現動詞
     這樣的url不對 /accounts/1/transfer/499
     應該是這樣 /accounts/1/transactions/499

     想想傳統的login、reset password在restful下要怎麼辦？

   • 動作用http method來表示
     針對CRUD，對應的語義分別是POST、GET、PATCH（PUT）、DELETE

     • GET、PUT、DELETE是冪等的，其餘不是
     • PATCH表示部分更新
     • PUT的確切語義是CREATE OR REPLACE

   • 使用http狀態碼來表示基礎的響應狀態

     • 200 操作成功
     • 400 請求有問題；如：參數驗證失敗、簽名驗證失敗等
     • 401 認證失敗。
     • 403 無訪問權限。
     • 409 請求處理完成但因爲業務規則限制或其他原因並未真正成功的響應
     • 500 服務器錯誤
     • 503 服務器維護中

3. 應有的支持

   • 版本化
     客戶端必須明確知道自己調用的API版本。
     兼容性被破壞時+1 https://api.expample.com/v1/endpoint
     爲了避免同時支持多版本API時，服務端消耗過多不必要的資源，應該以微服務的方式裁剪API，不同服務獨立部署、迭代。

   • 業務編號
     https://api.expample.com/v1/biz/0

   • 資源包升級
     客戶端不放資源包升級的邏輯，只發出升級請求，是否升級完全由服務端決定。

   • 強制升級
     特殊情況下要求客戶端連主程序包括資源包都必須升級。

   • https
     可以使用自簽名證書

4. 數據查詢DSL(?)

   允許客戶端直接提交DSL文本，自行決定要查詢一種或多種資源，查詢多種資源時，支持JOIN，並且支持結果集過濾、排序。

   • DSL只讀，結果集僅以二維表體現
   • url表示的資源只支持單個資源的讀寫
   • 批量資源的寫操作使用業務編號
   • 需要特殊結構的數據使用數據集編號

應用設計

1. 微服務

   從傳統的monolithic風格到microservice，就好比原來是所有人一起搭一輛大巴前往目的地，現在改成三五成羣，各自自駕前往。

   • 優勢在於小規模獨立部署及迭代，不必牽一髮動全身，靈活
   • 未必會更方便、未必會降低成本，需要具體問題具體分析以及依賴具體實踐
   • 開發工程微服務化及部署微服務化是兩回事

2. 使用spring mvc搭載應用

   把應用的依賴抽象成諸多service（注意，這裏說的service與前文說微“服務”不是同一事物；以及這些service是不帶業務邏輯的），可能包括且不限於：

   • session
   • cache
   • storage
   • relational db/orm
   • log
   • auth
   • httpclient
   • qrcode
   • image processing
   • config
   • queue
   • mail
   • sms
   • event
   • schedule

3. 後臺管理

   • cli
     面向運維及開發。

   • web
     面向業務及運營。