通過OPTIONS交換schema

在web開發中，經常遇到的一個問題是接口調用方和提供方經無法有效協調接口，導致前後端扯皮時有發生。

實際上，這主要是沒有統一的驗證標準，文檔理解不同，校驗邏輯不同。出錯的時候，分不清是調用方傳參錯誤還是服務端接口錯誤。

跨團隊、跨框架、跨語言還會放大這個問題。

通過OPTIONS交換schema這套方案，以上就不是問題了，OPTIONS提供的schema就是標準，提供者可以驗證自己提供的api對不對，調用者可以直接驗證自己的請求對不對。

簡單示例：

客戶端                          服務端
  │                               │
  ├── OPTIONS /api/v1/users ──────►
  │◄──── MetaMessage Schema ──────┤
  │     (struct definition)       │
  │                               │
  ├── POST /api/v1/users ────────►
  │◄──── MetaMessage Response ────┤

服務端的請求綁定了這個Schema，只有符合這個Schema才能合法請求；而客戶端發出的請求也必須符合這個Schema。

同時，因為這個OPTIONS是和正常的數據接口同時提供的，所以客戶端可以通過這個OPTIONS接口來獲取這個Schema。

Schema保證了客戶端和服務端的請求和響應格式一致，避免了因格式不一致導致的問題。

做完這些，考慮到實際應用中的問題，我們還需要考慮到以下問題：

OPTIONS是否需要每次請求都發送一次？

我們可以通過緩Schema來避免每次請求都發送一次。

對於服務端，由於接口程序啟動後就不會變了，實際只需要緩存一次，每次請求，直接返回就行了，基本沒有開銷。服務端返回的header中有Access-Control-Max-Age和Schema-Md5這兩個字段。

對於客戶端，通過Access-Control-Max-Age字段，我們可以知道服務端缓存的時間，從而知道是否需要每次請求都發送一次。
通過Schema-Md5字段，我們可以知道服務端返回的Schema是否變了，從而知道是否需要重新發送請求。

比如把Access-Control-Max-Age設置為24小時，那麼客戶端在24小時內，不需要每次發送請求都發送一次OPTIONS。
如果24小時內，服務端返回錯誤信息（服務端驗證Schema-Md5），說Schema變了，那麼客戶端需要重新發送OPTIONS請求，獲取最新的Schema保存起來。

metamessage/mm-web-py提供了python服務端的客戶端的相關實現，大家可以直接使用來簡化這些操作。這個倉庫提供了fastapi、flask、django的封裝。

metamessage/mm-web-go是golang的實現，支持gin、echo、fiber、chi、net/http（原生）。