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的一个很好的替代方案。