HATEOAS是否會增加對服務器的呼叫數量？

Question

我從來沒有使用HATEOAS和RESTAPI，而我所瞭解的是HATEOAS，不需要存儲URI和服務器send的URI就可以用來獲取其他資源或相關資源。

但是用HATEOAS，我們是不是增加了電話的數量？ 如果我想獲取客戶訂單信息，並且如果我首先獲取客戶信息並動態獲取訂單的URI，是不是額外的電話？

鬆散耦合可以理解，但我不明白這個成熟度級別的REST的確切用法。

Answer 1

HATEOAS爲什麼要增加所需要求的數量？如果沒有服務返回URI，客戶端可以使用它來執行狀態轉換（收集更多信息，調用某些任務，...），客戶端必須具有關於如何構建URI本身的一些知識（因此它與服務緊密耦合），儘管客戶端仍然需要調用服務器端的端點。所以HATEOAS只是移動關於如何從客戶端到服務器生成URI的知識。

通常發送到服務器的進一步請求並不是真正的問題，因爲無論如何每個調用都應該是無狀態的。如果您有一個負載平衡的服務器結構，那麼額外的請求並不會對服務器產生明顯的性能影響。

如果您關心客戶端向服務器發出的請求數量（無論出於何種原因），您可能會看一下HAL JSON，您可以在其中嵌入子資源的內容，但對於客戶這可能會對性能產生重大影響，就好像用戶可能擁有大量已發佈的訂單一樣，響應可能相當巨大，即使客戶不使用它，它也必須管理所有數據。通常，而不是在響應中嵌入大量列表項，服務會將客戶端指向URI，客戶端可以根據需要學習如何檢索這些信息。通常這種URI提供了對數據的可分頁視圖（如客戶下的訂單）。

儘管可分頁請求會增加服務處理的數量或請求數量，但總體性能會提高，但服務不必將整個訂單數據返回給客戶端，因此減少了後臺數據庫的負載以及縮小實際響應內容的長度。

爲了總結我的文章，HATEOAS旨在將創建URI的邏輯從客戶端調用到服務器，從而進一步將客戶端與服務分離。客戶不得不發佈的實際請求數量並不適合HATEOAS，而是整個API設計和客戶端的要求。