REST是构建API的一种流行方法，而且比GraphQL应用更广泛，让我们看看GraphQL和REST的区别。
Rest是一个概念
REST是一个事实上的架构标准，但它实际上没有规范，有大量的非官方定义。GraphQL有一个规范草案，它是一种查询语言，而不是一个架构，有一套围绕它的定义良好的工具（和一个繁荣的生态系统）。
REST是建立在现有的架构之上的，如HTTP，而GraphQL则是建立自己的一套规则。这可能是一个优势点，也可能不是，因为REST可以使用HTTP层上的缓存。GraphQL必须在系统中建立自己的缓存。
单一的端点
GraphQL只有一个端点，你在那里发送你的所有查询。通过REST方法，你创建了多个端点，并使用HTTP动词来区分读取动作（GET）和写入动作（POST、PUT、DELETE）。GraphQL不使用HTTP动词来确定请求类型。
根据您的需求定制
使用REST，您通常无法选择服务器返回给您的内容，除非服务器实现部分响应稀疏字段集，并且客户端使用该功能。 API维护人员无法强制执行此类过滤。
API通常会返回比你需要的多得多的信息，除非你也负责API服务，并为每个不同的请求定制响应。
在GraphQL中，情况就不同了：你向一个端点发出一个请求，只取回你需要的东西。
它避免了服务端大量冗余数据的返回，查询速度更快，更灵活。
下面我们来看一个Pizza endpoint的例子。
如果你调用GET /pizza/margherita，你将得到一个Margherita比萨。如果你调用GET /pizza/napoli，你将得到一份Napoli比萨。
如果你有30种不同的口味，你就会有30个端点（除非你把比萨饼的名字作为参数传给GET /pizza)
但也许你想要一种特定的比萨，这很容易向服务员描述，但很难向REST endpoint表达。
一个GraphQL端点可以让你调用/pizza，描述你要求的特定成分，以建立你想要的完美比萨。
GraphQL使监测字段的使用变得容易
在REST中，通常没有办法确定一个字段是否被客户端所需要，所以当涉及到重构或废弃时，不可能确定实际的使用情况。
GraphQL可以知道哪些字段被客户使用。
访问嵌套的数据资源
GraphQL产生更少的网络请求。
举个例子。访问一个人的所有朋友的姓名。如果你的REST API暴露了一个端点/person/1/friends，返回一个人朋友的信息列表，你首先通过GET /person/1得到/person/1，然后GET /person/1/friends。
除非一个人的朋友列表已经包含了朋友的名字，否则如果有100个朋友，你就需要向/person端点做101次HTTP请求，这是一个巨大的时间和资源的浪费。
使用GraphQL，你只需要一个请求，即询问一个人的朋友的名字。
类型
API是基于JSON的，不能提供类型控制。GraphQL有一个类型系统。
哪一个更好？
现在，全世界的开发者正试图找出从REST迁移到GraphQL是否适合他们的需求。
当你需要公开复杂的数据表示时，客户可能只需要数据的一个子集，或者他们经常执行嵌套查询以获得他们需要的数据时，GraphQL是一个完美的选择。
与编程语言一样，没有单一的赢家，这完全取决于你的需求。
另外，我想说的是：你可以同时使用。
你可以根据你的需要混合和使用REST和GraphQL，有时这是最好的做法。