GraphQL API与REST API
Since REST is such a popular approach to building APIs, and much more widespread than GraphQL, it’s fair to assume you are familiar with it, so let’s see the differences between GraphQL and REST.
由于REST是构建API的一种流行方法，并且比GraphQL广泛得多，因此可以假设您熟悉它是公平的，因此让我们来看看GraphQL和REST之间的区别。
休息是一个概念 (Rest is a concept)
REST is a de-facto architecture standard but it actually has no specification and tons of unofficial definitions. GraphQL has a specification draft, and it’s a Query Language instead of an architecture, with a well defined set of tools built around it (and a flourishing ecosystem).
REST是事实上的体系结构标准，但实际上它没有规范，并且有大量的非正式定义。 GraphQL有一个规范草案，它是一种查询语言，而不是一种体系结构，围绕它构建了一套定义良好的工具(以及蓬勃发展的生态系统)。
While REST is built on top of an existing architecture, which in the most common scenarios is HTTP, GraphQL on the other hand is building its own set of conventions. Which can be an advantage point or not, since REST benefits for free by caching on the HTTP layer.
REST建立在现有体系结构(在最常见的场景是HTTP )的基础上，而GraphQL在构建自己的约定集。 这可能不是优势点，因为REST通过在HTTP层上进行缓存而免费受益。
单一端点 (A single endpoint)
GraphQL has only one endpoint, where you send all your queries. With a REST approach, you create multiple endpoints and use HTTP verbs to distinguish read actions (GET) and write actions (POST, PUT, DELETE). GraphQL does not use HTTP verbs to determine the request type.
GraphQL只有一个端点，您可以在其中发送所有查询。 使用REST方法，您可以创建多个端点并使用HTTP 动词来区分读取动作( GET )和写入动作( POST ， PUT ， DELETE )。 GraphQL不使用HTTP动词来确定请求类型。
根据您的需求量身定制 (Tailored to your needs)
With REST, you generally cannot choose what the server returns back to you, unless the server implements partial responses using sparse fieldsets, and clients use that feature. The API maintainer cannot enforce such filtering.
使用REST，通常不能选择服务器返回给您的内容，除非服务器使用稀疏字段集实现部分响应，并且客户端使用该功能。 API维护者无法强制执行此类过滤。
The API will usually return you much more information than what you need, unless you control the API server as well, and you tailor your responses for each different request.
API通常会向您返回比您需要的信息更多的信息，除非您也控制API服务器，并且针对每个不同的请求量身定制响应。
With GraphQL you explicitly request just the information you need, you don’t “opt out” from the full response default, but it’s mandatory to pick the fields you want.
使用GraphQL，您可以显式地仅请求所需的信息，而不必从完整的响应默认值中“退出”，但是必须选择所需的字段。
This helps saving resources on the server, since you most probably need less processing, and also network savings, since the payload to transfer is smaller.
这有助于节省服务器上的资源，因为您最有可能需要较少的处理，并且由于要传输的有效负载较小，因此还可以节省网络。
A great way to visualize this is an example of a Pizza endpoint (I’m Italian, a Pizza example is perfect).
可视化的一种好方法是使用Pizza端点的示例(我是意大利人，Pizza的示例很完美)。
If you call GET /pizza/margherita, you will get the a pizza Margherita. If you call GET /pizza/napoli, you will get a pizza Napoli.
如果您致电GET /pizza/margherita ，您将获得一个比萨饼Margherita。 如果您致电GET /pizza/napoli ，您将获得一个比萨那不勒斯。
If you have 30 different flavors, you’ll have 30 endpoints (unless you pass the pizza name as a parameter to GET /pizza, for example)
如果您有30种口味，则将有30个端点(例如，除非将披萨名称作为参数传递给GET /pizza )
But maybe you want a specific kind of pizza, but without one ingredient you don’t like. That’s easy to ask to the waiter, but kinda hard to express to a REST endpoint.
但是，也许您想要一种特定的披萨，但是如果没有一种食材，您就不会喜欢。 这很容易向服务员询问，但是很难表达给REST端点。
A GraphQL endpoint would let you call /pizza, and you ask for specific ingredients, to build the perfect pizza you want.
GraphQL端点会让您调用/pizza ，然后您需要特定的配料来构建所需的完美披萨。
GraphQL使其易于监视字段使用情况 (GraphQL makes it easy to monitor for fields usage)
With REST usually there is no way to determine if a field is needed by the client, so when it comes to refactoring or deprecating, it’s impossible to determine actual usage.
使用REST通常无法确定客户端是否需要一个字段，因此在进行重构或弃用时，无法确定实际使用情况。
GraphQL makes it possible to track which fields are used by clients.
GraphQL使得可以跟踪客户端使用哪些字段。
访问嵌套的数据资源 (Access nested data resources)
GraphQL allows to generate a lot less network calls.
GraphQL允许生成更少的网络调用。
Let’s do an example: you need to access the names of the friends of a person. If your REST API exposes a /person endpoint, which returns a person object with a list of friends, you generally first get the person information by doing GET /person/1, which contains a list of ID of its friends.
让我们举个例子：您需要访问一个人的朋友的名字。 如果您的REST API公开了/person端点，该端点返回带有好友列表的person对象，那么通常通常首先通过执行GET /person/1获取该人物信息，该列表包含其好友的ID列表。
Unless the list of friends of a person already contains the friend name, with 100 friends you’d need to do 101 HTTP requests to the /person endpoint, which is a huge time cost, and also a resource intensive operation.
除非一个人的朋友列表中已经包含该朋友的名称，否则您需要与100个朋友向/person端点进行101个HTTP请求，这将花费大量时间，并且也是一项资源密集型操作。
With GraphQL, you need only one request, which asks for the names of the friends of a person.
使用GraphQL，您只需要一个请求即可询问一个人的朋友的名字。
种类 (Types)
A REST API is based on JSON which cannot provide type control. GraphQL has a Type System.
REST API基于无法提供类型控制的JSON。 GraphQL具有类型系统 。
哪一个更好？ (Which one is better?)
Organizations around the world are questioning their API technology choices and they are trying to find out if migrating from REST to GraphQL is best for their needs.
世界各地的组织都在质疑他们的API技术选择，他们试图找出从REST迁移到GraphQL是否最适合他们的需求。
GraphQL is a perfect fit when you need to expose complex data representations, and when clients might need only a subset of the data, or they regularly perform nested queries to get the data they need.
当您需要公开复杂的数据表示形式，或者客户端可能只需要数据的一个子集，或者客户端定期执行嵌套查询以获取所需的数据时，GraphQL是一个完美的选择。
As with programming languages, there is no single winner, it all depends on your needs.
与编程语言一样，没有唯一的赢家，这完全取决于您的需求。
Also, there’s a point I want to make: you can use both.
另外，我想说一点：您可以同时使用两者。
You can mix and match REST and GraphQL depending on your needs, and sometimes it’s the best thing to do.
您可以根据需要混合和匹配REST和GraphQL，有时这是最好的选择。