GraphQL並不是要取代REST，它是固執己見的，並且在設計時考慮了特定的約束。它是一種強大的查詢語言，可以讓客戶端掌控一切。但取決於具體情況，這可能是好的或壞的做法！

RESTful API可能難以正確設計。我的意思是那些利用HATEOAS的人。但是一旦你做對了，它就會非常強大。特別是在機器到機器的互動中。另一方面，根據我的經驗構建RESTful客戶端非常困難。

為什麼RESTful客戶端難以構建？至少我可以根據我的經驗中這麼認為。因為沒有單一方法可以解釋例如諸如如何設計嵌入式連結和集合。實現方法有不同的格式，如HAL，Json-LD，Collections + Json，Siren ...每個都有優缺點。

有時選擇一個定義良好的協議作為ATOM可能是最好的解決方案。否則，選擇正確的格式可能很困難，因為在特定上下文中使用它之前需要知道的重要差異。

另一個問題是如果你使用React，Angular和其他東西構建Ux客戶端。一般來說，你可能忘記了解析連結等問題。框架/庫存在有自己的方式，很難繞過它自己的客戶端路由方式。

另一方面，GraphQL使用Apollo等方式更容易進行Ux客戶端開發。GraphQL支持者宣傳它比REST更好，因為沒有資料的查詢不足/查詢過多等問題，但它也需要正確設計知識和經驗。

GraphQL api：必須受到保護，不要被過於複雜的查詢（最大深度，白名單等）攻擊：

•  - 在客戶端正確捕獲
• - 必須優化解析器（捕獲和批處理）
• - 優化和正確設計資料載入器。
• - 版本控制

GraphQL在二進位制資料方面也存在一些問題。即使上傳小影象也需要Base64編碼（較慢），或者必須與另一個API端點混合以進行二進位制資料操作。

有些人還使用GraphQL作為機器與機器之間的互動或將其用於微服務架構，但對我來說這似乎是一個壞主意。當然我也有興趣聽聽現實世界的經歷。

在我目前的上下文中，我們發現使用GraphQL對於Ux客戶端開發更容易。

我的方法是：在UX中使用Graphql - > b/e(API)，而REST用於m2m（機器到機器 SPI），最終grpc可能是m2m的一個很好的替代方案。