通過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（原生）。
