本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 為什麼在 REST 上使用 GraphQL？
<a name="why-use-graphql"></a>

REST 是 Web APIs 的基石架構樣式之一。不過，隨著世界變得更加相互連結，開發強大且可擴展的應用程式的需求將成為更緊迫的問題。雖然 REST 通常用於建置 Web APIs，但已識別 RESTful 實作的經常性缺點如下：

1. **資料請求**：使用 RESTful APIs，您通常會透過端點請求所需的資料。當您的資料可能無法妥善封裝時，就會發生問題。您需要的資料可能位於多層抽象後面，而擷取資料的唯一方法是使用多個端點，這表示提出多個請求來擷取所有資料。

1. **過度擷取和低擷取**：若要將 新增至多個請求的問題，系統會嚴格定義每個端點的資料，這表示即使您在技術上不想要該 API，您仍會傳回為該 API 定義的任何資料。

   這可能會導致*過度擷取*，這表示我們的請求會傳回多餘的資料。例如，假設您正在請求公司人員資料，並想要知道特定部門的員工名稱。傳回資料的端點將包含名稱，但也可能包含其他資料，例如職稱或出生日期。由於 API 是固定的，您無法僅請求名稱，其餘資料會隨附於它。

   相反的情況是，我們未傳回足夠的資料稱為*擷取不足*。若要取得所有請求的資料，您可能需要向服務提出多個請求。視資料的結構方式而定，您可能會遇到效率不佳的查詢，導致 n\$11 問題等問題。

1. **緩慢的開發反覆運算**：許多開發人員會量身打造 RESTful APIs，以符合其應用程式的流程。不過，隨著應用程式的成長，前端和後端都可能需要大量的變更。因此，APIs可能不再符合資料形狀的效率或影響力。由於需要 API 修改，這會導致產品反覆運算速度變慢。

1. **大規模效能**：由於這些複合問題，許多領域會影響可擴展性。應用程式端的效能可能會受到影響，因為您的請求會傳回太多資料或太少 （導致更多請求）。這兩種情況都會對網路造成不必要的壓力，導致效能不佳。在開發人員方面，開發速度可能會降低，因為您的 APIs 是固定的，不再符合他們請求的資料。

GraphQL 的賣點是克服 REST 的缺點。以下是 GraphQL 提供給開發人員的一些重要解決方案：

1. **單一端點**：GraphQL 使用單一端點來查詢資料。您不需要建置多個 APIs來符合資料的形狀。這會導致較少的請求通過網路。

1. **擷取**：GraphQL 只需定義您需要的資料，即可解決擷取過多和不足的常年問題。GraphQL 可讓您將資料塑造成符合您的需求，因此您只會收到您要求的內容。

1. **抽象：**GraphQL APIs 包含一些元件和系統，這些元件和系統使用語言無關的標準來描述資料。換句話說，資料的形狀和結構是標準化的，因此前端和後端都知道如何透過網路傳送資料。這可讓兩端的開發人員使用 GraphQL 的系統，而不是在其周圍。

1. **快速反覆運算**：由於資料標準化，在開發的一端可能不需要變更。例如，前端呈現變更可能不會導致大量的後端變更，因為 GraphQL 允許輕鬆修改資料規格。您可以直接定義或修改資料的形狀，以符合應用程式的成長需求。這會導致較低的潛在開發工作。

這些只是 GraphQL 的一些優點。在接下來的幾個區段中，您將了解 GraphQL 的結構方式，以及讓它成為 REST 獨特替代方案的屬性。