什么是 GraphQL？
GraphQL 是一种与 API 交互的替代方式，非常适合复杂的数据结构和在其之上构建接口。与将数据视为独立的、独立的部分不同，GraphQL 显示数据部分如何连接和相关，使得请求和接收信息变得容易。
将 GraphQL 视为一种查询语言，允许您与 API 进行交互，就好像直接与数据库交谈一样。使用 GraphQL 可以尽可能接近数据库，让您自由选择所需的数据以及获取方式，提供巨大的性能优势。
GraphQL 是由 Facebook 创建的 以解决复杂数据结构的扩展问题。由于他们成功采用了它，越来越多的公司开始意识到使用 GraphQL 为他们的 API 带来的好处。
与 REST 的主要区别
GraphQL API 比您想象的更易于使用。如果您习惯使用 REST API，以下是需要牢记的基本区别：
| 特征 | REST | GraphQL |
|---|---|---|
| 端点 | 针对不同操作向多个端点发出请求 | 所有请求都发送到单个端点（例如，/graphql） |
| 数据检索 | 使用 GET 方法在特定端点检索数据 | 使用 查询 请求确切需要的数据，减少过度获取或不足 |
| 数据修改/操作 | 使用 HTTP 方法 如 POST、PUT、PATCH 或 DELETE 修改或处理数据。 | 使用 mutations 执行操作（例如，创建 parties，计算 landed costs） |
| 响应格式 | 固定的响应格式返回所有预定义字段，无论是否需要 | 灵活的响应允许指定要包含的字段，减少不必要的数据传输 |
| 数据连接 | 通常需要多个请求来获取相关数据 | 嵌套查询使得能够在单个请求中检索相关数据（例如，一起获取 party 详细信息和 shipment 项目）。用户还可以构建工作流，在单个 GraphQL 请求中管理多个 mutations，减少复杂性并提高效率 |
GraphQL 的优势
更快的响应
GraphQL 通过精确的数据检索、使用单个端点以及改进的批处理和缓存功能提供更快的响应。
精确的数据检索
使用 REST 的一个常见挑战是过度获取或不足获取数据——要么获取太多不必要的信息，要么获取不到所需的信息。GraphQL 通过允许请求确切需要的数据来消除这一问题——既不多也不少。这种具体性不仅提高了性能，还简化了与 API 交互的流程，使系统更高效和用户友好。
这种用法的示例：
- 这使得前端开发人员可以获取其 UI 组件所需的确切数据，减少与服务器的往返次数，提高性能。
- 想象一下，您想要获取一个 landed cost 中项目的 HS 编码分类装箱、运输评级和 checkout 报价。如果您通过 GraphQL API 进行集成，您可以使用必要的 工作流 进行单个调用，以获取您需要的一切（而不需要的内容）。相比之下，使用 REST API，您需要首先调用 Classify REST API，然后单独调用 Rating REST API，最后将分类和运输评级插入到您对 Landed Cost REST API 的第三个调用中。所有这些 REST API 都会返回它们可以提供的所有信息，导致您必须解析响应以获取所需的数据。这种速度上的节省对于在购物者离开之前快速返回完整的 landed cost 产生影响。
单个端点
GraphQL API 通常只有一个端点，而 REST API 经常有多个端点用于不同的资源和操作。这使得管理和理解 API 更简单。
批处理和缓存
GraphQL 的批处理查询能力和对缓存策略的支持带来了显著的性能改进。这些功能减少了网络和服务器的负载，为用户提供更快、更可靠的交互。
明确定义的模式
GraphQL API 基于强类型模式。该模式定义了可用数据的结构和可执行的操作。这提供了关于可用数据及如何访问的清晰度，可以提高开发人员的生产力并减少错误。例如，前端团队可以探索图形以获取他们需要的内容，而不必等待新的 REST 端点。
能够改进而不破坏现有客户端
在 GraphQL 中添加新功能或修改现有功能不会破坏当前的集成，这要归功于其灵活的查询结构。这种能力确保可以进行改进而不会破坏与现有客户端的兼容性。
最新的文档
由于 GraphQL 的内省功能，文档会自动生成并随着每次更改而更新。这确保向开发人员提供的所有信息都是最新的，减少了与过时文档相关的集成问题和支持票证——这是 REST API 文档常见面临的挑战。
查看我们的 GraphQL 文档 和我们的 REST 文档 以了解差异。
类比
想象一下你在一家餐厅，菜单让你可以按照自己的喜好点菜，而另一家餐厅只能选择固定的套餐。GraphQL就像第一家餐厅：
- 准确获取你想要的东西： 使用GraphQL，你可以请求你所需的确切数据，不多也不少。想象一下你只想要一道菜的名称和价格，而不是整个配料清单。使用REST API，你必须获取整个菜品的详细信息，并忽略你不需要的部分。
- 组合自定义菜品： 我们的GraphQL API可以轻松组合，以创建更自定义的解决方案，类似于自助餐厅，你可以根据需要创建独一无二的菜品，使用他们已经有的食材。相比之下，REST API就像一家有预制商品的面包店——你只能点已经制作好的商品，不能选择只带回你想要的那一部分。
- 减少等待时间： 由于你可以在一次请求中获取所需的所有信息，就像要求服务员一次性把开胃菜、主菜和甜点都端上来，而不是在每道菜之间等待。大多数REST API要求你发送多个请求以获取不同的信息。
- 轻松更改订单： 如果你的应用数据需求发生变化，GraphQL使得调整变得更容易。你只需更改查询以获取所需内容。使用REST，你可能需要等待厨房（后端）为菜单创建新菜品（端点），这需要更多时间。
GraphQL在获取数据方面提供了比REST API更多的灵活性、效率和简便性，尤其是在你的需求变化或增长时。
Zonos 如何使用GraphQL
在过去的几年中，我们在现代化平台的过程中，Zonos选择使用GraphQL构建新的API功能，而不是REST。我们之所以这样做，是因为我们的数据复杂且相互关联，类似于Facebook创建GraphQL的数据。这种复杂性使得构建可扩展的REST API变得具有挑战性，因为开发者获取和使用数据的方式在实现之间差异很大，而REST并不灵活。
GraphQL巧妙地解决了这个问题，允许实现我们API的开发者精确选择他们想要的数据及其获取方式。这使得他们能够将其融入到他们的工作流程中，而不需要Zonos在每种情况下都进行定制工作（在他们等待时）。
使用GraphQL和我们平台现代化的结合结果使我们的API性能更佳，使得将Zonos集成到你的系统中更快，并使得Zonos能够更快地交付新功能。
更好的功能
Zonos持续开发新功能，而GraphQL是第一个（通常也是唯一一个）接收这些更新的。相比之下，我们的REST API被视为生命周期结束，无法访问许多新功能。
限于GraphQL的功能示例：
- Inclusive pricing
- 标签API
- 新的Checkout和Hello
- API响应中的箱子尺寸
- 仪表板报告
- 如果可能，能够请求DDP报价，但如果该服务级别的DDP对该国不可用，则仍返回DDU报价
- 详细的关税、税费和费用分解（逐项信息，具体费用）——仪表板由GraphQL提供支持，并显示所有商店的数据，但REST API响应不包括此级别的详细信息
- 测试模式（即将推出）
为什么使用 GraphQL
了解为什么我们建议通过 GraphQL 而不是 REST 进行集成。
在 Zonos，我们提供两种主要类型的 API 用于集成：GraphQL 和 REST。虽然 REST API 已经存在较长时间，对许多人来说可能更为熟悉，但我们已经转向 GraphQL，以提供更灵活和更快速的创新。虽然两者仍然受支持，但本指南解释了为什么 GraphQL 不仅是我们集成的未来，也是一般集成的未来，是满足您今天需求的更强大工具。