“REST API”作为API设计方法早已成为行业标准。然而，近年来，随着前端变得越来越复杂，越来越多的公司开始采用 GraphQL。 在讨论技术细节之前，我们首先以在餐厅点餐为例来思考一下两者之间的区别。
REST API 在餐厅中的局限性
REST API 就像一个“美食广场”，每个菜单都有不同的柜台。
例如，假设您想订购一份汉堡包套餐。您必须首先前往汉堡柜台（/api/burgers/1），然后前往土豆柜台（/api/sides/potato），最后前往饮料柜台（/api/drinks/coke）。
这就需要多次来回柜台（多次请求）的麻烦。此外，即使你想把汉堡中的泡菜去掉，柜台也会给你带有泡菜的成品。这是一个称为“过度获取”的问题，即检索不必要的数据。
名为 GraphQL 的终极定制
另一方面，GraphQL 是“非常能干的私人服务员”。 你递给服务员一份订单（查询），上面写着“汉堡（不含泡菜）、小份薯条和可乐”。然后服务员去厨房，把你指定的东西端到一个托盘上。
这是GraphQL最大的特点。前端（客户）可以准确指定他们想要什么数据以及以什么形式，后端将相应地返回准确的数据量。
GraphQL 的好处和实施障碍
该机制具有以下优点：
- 减少通信量： 在智能手机等移动环境中，不获取不必要的数据可以显着提高性能。
- 灵活的UI更改： 即使您想向屏幕添加新的显示项，也不需要像REST中那样让后端创建新的端点，只需重写前端查询即可完成。
另一方面，它不是一根魔杖。 还有诸如“缓存难以控制”、“容易出现N+1问题”、“后端实现变得更加困难”等问题。对于简单的博客网站，REST API往往更简单、更合适。
你应该选择哪一个？
GraphQL 是开发在单个屏幕上显示多种类型资源（用户信息、帖子、评论、点赞等）的复杂 Web 应用程序的最佳选择。 确定您的“餐厅”收到最多的订单类型并选择合适的架构。