GraphQL和Fieldings REST約束

Question

在他dissertation，Fielding定義了一組規則，應符合REST API。

這包括除其他外以下規則：

• 客戶端 - 服務器
• 無國籍緩存接口
• 統一合同（超媒體或HATEOAS，..）
• 分層系統

是否有可能滿足GraphQL這些要求？

雖然點的客戶端 - 服務器，無狀態和分層系統很可能實現，我不知道該點緩存和統一的合同。

Answer 1

讓我們通過Fieldings約束和檢查GraphQL滿足他們：

客戶 - 服務器架構 - YES

GraphQL是（主要）的查詢語言，從客戶機到服務器指定的查詢。

無國籍 - YES

對此進行詳細here dicussed。 簡短的回答是肯定的，GraphQL是無狀態的，因爲沒有會話的概念和服務器並不需要任何額外的信息來處理請求。

緩存能力 - NO

這一個是棘手。從技術上講，您可以在HTTP請求級別緩存GraphQL查詢（如果您use HTTP）。但是，由於客戶端可以查詢對象和屬性的任意組合，因此這種緩存的命中率可能很低，並且緩存的信息高度冗餘。正因爲如此，GraphQL開發者建議graph-based caching approach。然而，這種方法需要全局唯一標識符，介紹關於GraphQL規格之上的附加約束，即可疑類似於REST的「資源標識」的約束（見下文）。

另一種方法是推遲緩存到到GraphQL服務器提供數據的其他組件，但這是無關GraphQL本身。鑑於上述情況，我會說GraphQL請求默認情況下不可緩存。

分層系統 - YES

守備described分層架構作爲一個......

...通過約束構件行爲分級層組成 使得每個組件不能「看到」超出與他們正在交互的 的即時層。

您可以設置一個GraphQL服務器來轉發請求到其他GraphQL服務器，而客戶端不知道它。實際上，GraphQL服務器通常用作「前端後端」，用於彙總客戶端不知道的其他服務的數據。這是一個分層系統。

接口/制服合同 - NO

這個約束通常通過四個子約束配製：

資源

• 鑑定 - NO

如上所述， GraphQL不提供統一的機制來識別資源ES。該GraphQL documentation狀態：

HTTP通常與REST，它使用的「資源」爲 核心理念有關。相比之下，GraphQL的概念模型是一個實體 圖。因此，GraphQL中的實體不會被URL標識。經過交涉資源

• 操作 - （？）是

假設GraphQL的資源是數據對象，並轉移JSON（或其他格式）是表示（而不是將整個GraphQL端點視爲單個資源）。然後，將變異的JSON表示發送回服務器以更新對象是可能的。

• 自描述性消息 - NO

這一個是，在我看來，見仁見智（？）。何時是一個自我描述的信息？如果目標是通過客戶端和服務器之間的任意引入的中間層「可以理解」，那麼我認爲GraphQL消息不是自描述性的。查詢或變化的結構只在服務器模式的上下文中才有意義。可以從服務器請求此架構，但這會擴展單個消息的範圍。

• 超媒體作爲應用狀態（HATEOS）的發動機 - NO

這一個是簡單的。 GraphQL根本不支持鏈接的概念，鏈接是超媒體的前提和本質。 This article對這個主題有一些有趣的看法。

代碼點播（可選） - NO

是從GraphQL服務器發送到客戶端的所有數據被鍵入。沒有支持的類型打算執行。表示動作的變異請求僅從客戶端發送到服務器，而不是其他方向。當然，始終可以將代碼作爲文本發送，但這可能不是GraphQL的設計目的。

---

總之，GraphQL不符合所有REST要求。這可能不是有意的。它旨在解決由REST原理引起的一些問題，主要是客戶端需要多次HTTP往返才能獲取單個對象圖，並反過來接收比實際使用的更多的數據。