为什么REST比GraphQL更好? - TomaszJaskuλa

19-09-04 banq
                   

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

                   

2