我致力于將單體應用拆分為微服務。有了單體應用，我有一個單一的事實來源，并且可以GET /resources/123立即PATCH /resources/123確保資料庫具有我需要的最新資料。
有了微服務和 CQRS，當我執行 GET 請求時，查詢服務可能還沒有看到對記錄的最新更新。
確保客戶收到最新價值的最佳或標準方法是什么？我知道客戶端可能會比較他在之后PATCH和之后收到的資源版本GET并重試請求，但是是否有已知的 API 設計來告訴服務器類似的東西GET /resources/123 and wait up to 5 sec for the resource version 45 or bigger to arrive？
uj5u.com熱心網友回復：
由于PATCH請求允許回應主體，因此在我看來，包括修補后的物件在內的回應沒有任何問題。發送 的請求者PATCH可以使用回應代替GET; 對于其他人來說，最終的一致性延遲GET是不可觀察的（因為他們不知道何時PATCH發布）。
CQRS 意味著不要為了讀取而扭曲您的寫入模型。如果基于寫入模型可以輕松執行讀取，則可以針對寫入模型進行讀取。
uj5u.com熱心網友回復：
一般來說，如果可以選擇，更好的設計可能是PATCH請求延遲自己的回應。
但是，您的GET請求也可以“掛起”，直到它準備好。這通常感覺比輪詢更好。
客戶端可以使用標頭向服務器指示它愿意等待多長時間Prefer: wait=：https ://datatracker.ietf.org/doc/html/rfc7240#section-4.3
這可以用于請求GET或PATCH請求。
我不認為有一個標準的 HTTP 方式可以說：這個資源現在不可用，但將來會。但是，有一個標準的 HTTP 標頭告訴客戶端何時重試請求：
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After
這主要用于 429 和 503 錯誤，但在這里似乎都不合適。
坦率地說，這是我一段時間以來聽到的第一件事，它可能是一個很好的新 HTTP 狀態代碼。425 Too Early存在，但它是一個不同的用例。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/418647.html
標籤：