這個題目很大，我只能撿一些我們開發產品時的重點來說

• API 有非常多種協定，HTTP、gRPC、SOAP 等等，以下我以 HTTP 為例。
• 文件
  • Follow OpenAPI 的格式的話，可能會看到 Swagger 的風格或是 ReDoc 的風格。這部分要採用那一套只要溝通好就好，只是要注意現在主流都已經支援 Live Document，也有許多工具讓前端可以直接用 OpenAPI Spec 直出 API Client 的程式碼或是生成靜態文件
• 設計
  • 這邊有一個關鍵詞是 Richardson Maturity Model，連結是 Martin Fowler 的 Blog 文章。從最基礎的第0層到最高階的第3層，我覺得重點是大家的 Context 要一致，畢竟是協作，如果一定要約束用標準 RESTFul 的第2層的設計方法(例如複數名詞結尾，用 HTTP 動詞來操作)，也不會保證溝通就順暢。依照我們的經驗是符合商業需求的前提下儘量降低前端的負擔，能一次給他的就不要讓他做多次，另外一次一次的迭代優化下還要保持向下相容。而要下向相容就又談到版本化 API，做法也有很多種，如 Query Parameter、Path Variable、Header、SubDomain、Accept Encoding、Request Body、Hypermedia 等等的做法，這邊各有長短，每種方法也都不算罕見，就依照團隊適合的做法去選擇即可。FooTinder 目前是用 Path Variable 來做，例如 /api/v1.0, /api/v2.0
• 測試
  • 這邊我想幫他補充一個前綴，End-to-End Testing。簡單來說就是 API 層級的端對端測試，所以重點在真正的接上資料庫，讓 邏輯流 與 資料流 真正的動起來。以我們來說，在 Build Time 的測試階段會用 Testcontainer 把外部相依來的服務如 MQ、DB 開起來，然後先加入測試資料，再進行 API 的調用與斷言，最後再將幾個 API 組合在一起變成一個前端調用的場景
• 安全
  • 這邊我也只能先以 Mobile App 的角度來談，因為沒了 Web 世界常見的 Cookie 和 Session，現在也流行一些其他的方法如 OAuth，那就是會放一個 Token 在 Header 上。對於後端來說就會偏向 Stateless 的範疇，誰擁有 Token 誰就可以互動和拿資料，保護議題就要放在是否合法安全的取得 Token，把這個責任丟給別人，像是 Google 登入、Apple FaceID 等等
• 監控
  • 這個就最單純了，最簡單驗證 HTTP 狀態碼是一種作法，如果希望可以覆蓋的更全面的話，建議就是把測試那個環節的端對端測試拿來用，讓 Build Time 的迴歸測試，擴展到 Runtime，模擬用戶的真實場景。當然在這邊我想要特別提到一件事，監控跟測試的重點都在不斷地迭代，我們不會一次就到位，也沒辦法寫一次用永遠，一定要一直反覆迭代優化

✌️ 那麼第五天到這邊囉，明天來講 -> 最小可行性產品，Minimum Viable Product

相關資訊

• $_purefunc 純函式公司
• FooTinder App站
• FooTinder App 下載連結