什么是 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 不仅是我们集成的未来,也是一般集成的未来,是满足您今天需求的更强大工具。