在鸡尾酒搅拌机上见GraphQL

REST和GraphQL是构建网站API的两种规范。REST定义了一系列唯一的标识符（URL），应用程序使用这些标识符来请求和发送数据。GraphQL定义了一种查询语言，允许客户端应用程序精确指定他们需要从单个端点获取的数据。它们是相关的技术，用于大致相同的事情（事实上，它们可以并且经常共存），但它们也截然不同。

让我们用一种更有趣的方式来解释它，这可能有助于你更好地理解，并可能让你对GraphQL有点兴奋！

? 你在一个鸡尾酒会上

你参加这个酒会是为了拓展你的职业人脉，所以自然地，你想要收集一些关于你周围人的数据。附近有五位其他与会者。

他们的名牌上写着：

• Richy REST
• Richy REST的朋友
• Richy REST的雇主
• Georgia GraphQL

作为你充满活力、社交、外向的本性，你径直走到Richy REST面前说：“你好，我是Adam Application，你是谁？”Richy REST回答：

<code>{
  name: "Richy REST",
  age: 33,
  married: false,
  hometown: "Circuits-ville",
  employed: true
  // ... Richy REST的其他20条信息
}</code>

“哇，这信息太多了，”你心里想着。为了避免任何尴尬的沉默，你记得Richy REST提到他被雇佣了，于是问道：“你在哪里工作？”

奇怪的是，Richy REST不知道他在哪里工作。也许Richy REST的雇主知道？

你向Richy REST的雇主问了同样的问题，他很乐意回答你的询问！他这样回答：

<code>{
  company: "Mega Corp",
  employee_count: 11230,
  head_quarters: "1 Main Avenue, Big City, 10001, PL"
  year_founded: 2005,
  revenue: 100000000,
  // ... Richy REST雇主的其他20条信息
}</code>

这时，你精疲力尽了。你甚至不想见Richy REST的朋友！那可能要花很长时间，耗尽你所有的精力，而且你没有时间。

然而，Georgia GraphQL一直礼貌地站在那里，所以你决定和她交流。

“你好，你叫什么名字？”

<code>{   
  name: "Georgia GraphQL"
}</code>

“你来自哪里，你多大了？”*

<code>{
  hometown: "Pleasant-Ville",
  age: 28
}</code>

“你有多少爱好和朋友，你的朋友的名字是什么？”

<code>{
  hobbies_count: 12,
  friends_count: 50,
  friends: [
    { name: "Steve" },
    { name: "Anjalla" },
    // ...等等
  ]
}</code>

Georgia GraphQL太棒了，清晰、简洁、切中要害。你100%想和她交换名片，并在未来的项目中和她一起合作。

这个故事概括了开发人员使用GraphQL而不是REST的经验。GraphQL允许开发人员用简洁的查询表达他们的需求，并且只接收他们指定的内容——不多也不少。这些查询是完全动态的，因此只需要一个端点。另一方面，REST具有预定义的响应，并且通常需要应用程序使用多个端点来满足完整的资料需求。

隐喻结束！让我们谈谈重点。

为了进一步阐述在鸡尾酒会隐喻中提出的基本概念，让我们具体讨论使用REST时经常出现的两个限制。

1. 获取相关资源时需要多次请求

数据驱动的移动和Web应用程序通常需要相关的资源和数据集。因此，使用REST API检索数据可能需要向多个端点发出多个请求。例如，请求Post实体和相关的作者可能需要向不同的端点发出两个请求：

<code>someServer.com/authors/:id
someServer.com/posts/:id</code>

多次访问API会影响应用程序的性能和可用性。对于低带宽设备（例如智能手表、物联网、旧款移动设备等）来说，这也是一个更重要的问题。

2. 数据过度获取和不足获取

使用RESTful API时，数据过度获取和不足获取是不可避免的。使用上面的例子，端点domainName.com/posts/:id获取特定Post的数据。每个Post都由属性组成，例如id、body、title、publishingDate、authorId等。在REST中，总是返回相同的数据对象；响应是预定义的。

在只需要Post标题和正文的情况下，会发生数据过度获取——因为发送到网络上的数据比实际使用的数据多。当需要整个Post及其作者的相关数据时，就会发生数据不足获取——因为发送到网络上的数据比实际使用的数据少。数据不足获取会导致由于对API的多次请求而过度使用带宽。

使用GraphQL进行客户端查询

GraphQL引入了一种真正独特的方法，为客户端应用程序提供了极大的灵活性。使用GraphQL，查询被发送到你的API，并且只返回你所需的内容——不多也不少——在一个请求中。查询结果以与你的查询相同的形状返回，确保响应结构始终可预测。这些因素允许应用程序运行得更快、更稳定，因为它们可以控制它们获取的数据，而不是服务器。

“结果以与查询相同的形状返回。”

<code>/* 查询 */
{
  myFriends(first: 2) {
    items {
      name
      age
    }
  }
}</code>

<code>/* 响应 */
{
  "data": {
    "items": [
      { "name": "Steve", "age": 27 },
      { "name": "Kelly", "age": 31 }
    ]
  }
}</code>

现实检验 ✅

现在，你可能认为GraphQL像用武士刀切热黄油一样容易。对于前端开发人员来说，这可能是现实——特别是那些使用GraphQL API的开发人员。然而，当涉及到服务器端设置时，有人必须制作香肠。我们的朋友Georgia GraphQL付出了很多努力才成为她现在如此出色的专业人士！

构建GraphQL API（服务器端）需要时间、精力和专业知识。也就是说，对于那些准备好迎接挑战的人来说，这并不是什么无法处理的事情！有很多不同的方法可以在所有抽象级别上参与其中。例如：

• 无辅助: 如果你真的想亲自动手，可以借助软件包来构建GraphQL API。例如，喜欢Rails？查看graphql-ruby。喜欢Node.js？试试express-graphql。
• 辅助: 如果完全维护你的服务器/自托管是一个优先事项，像Graph.cool这样的东西可以帮助你开始一个GraphQL项目。
• 即时: 厌倦了编写CRUD样板代码，想要快速上手？8base提供了一个即时的GraphQL API和无服务器后端，它是完全可扩展的。

总结

REST通过启用高度可用的资源特定API，为Web服务带来了巨大的进步。也就是说，它的设计并没有考虑到当今互联设备的激增，所有这些设备都有不同的数据限制和要求。这种疏忽很快导致了GraphQL（Facebook于2015年开源）的普及，因为它为前端开发人员提供了巨大的灵活性。使用GraphQL是一种很棒的开发体验，对于个人开发人员和团队都是如此。

以上是在鸡尾酒搅拌机上见GraphQL的详细内容。更多信息请关注PHP中文网其他相关文章！