REST API与GraphQL
Scrapeless Scraping API提供特定任务的HTTP接口，返回用于应用工作流的结构化公共网络数据。
TL;DR
- REST和GraphQL定义了不同的接口形状。 REST围绕资源和表示组织交互；GraphQL针对类型模式执行选择。
- 两种风格都不一定更快。 有效载荷形状、请求数量、缓存行为、解析器工作、数据库访问和网络条件决定性能。
- REST自然而然地与HTTP缓存对接。 GraphQL可以有效缓存，但通常需要操作感知的客户端或网关策略。
- GraphQL允许客户端进行字段级选择。 这种灵活性将更多需求控制和成本分析转移到服务器。
- 混合架构可以是合理的。 最佳边界应根据客户端、领域形状、操作和团队能力，而不是普遍优胜者。
一句话中的差异
REST是一种为围绕资源、表示和统一接口构建的分布式系统的架构风格；GraphQL是一种查询语言、类型系统和在其中客户端从模式中选择字段的执行模型。REST API通常暴露多个资源地址，并使用HTTP语义进行操作。GraphQL API通常通过共享端点接受操作，并解析选择树。
比较不是在JSON和非JSON格式之间的竞争。两者通常返回JSON，均可使用相同的数据库，并且都需要身份验证、授权、验证、监控和容量控制。GitHub的 REST和GraphQL API的官方比较 说明了一个实用的观点：一个平台可以同时支持这两者，并让消费者根据能力和熟悉程度选择。
请求模型的不同之处
REST API与GraphQL：差异与决策指导需要层次化的解释，因为其可见结果可能有多个原因。以下阶段将每个声明与系统的可观察部分相连。
REST资源交互
客户端寻址资源或集合，通过接口语义选择操作，提供输入，并接收表示。服务器定义响应形状。相关数据可能需要嵌入表示、稀疏字段选项或额外请求。
GraphQL选择执行
客户端提交一个类型化操作，其字段描述所需的响应。服务将文档验证与模式进行比对，解析字段，并返回与选择形状相似的数据。当模式暴露关系时，相关对象可以在同一操作中遍历。
操作后果
REST将工作负载分散在现有HTTP基础设施直接理解的地址和方法上。GraphQL在一个执行表面集中各种操作，因此操作名称、规范化文档、字段路径和估算成本成为重要的可观察维度。
REST API与GraphQL的并排比较
这些区别将REST API与GraphQL：差异与决策指导与附近常作同义词使用的术语区分开来。它们还揭示了文档必须声明的内容，以使实现可测试。
| 维度 | REST API | GraphQL |
|---|---|---|
| 主要合同 | 资源、表示、方法、媒体类型和链接。 | 一种强类型模式和可执行的操作文档。 |
| 响应形状 | 由服务器选择，有时带有字段或包含参数。 | 由客户端在模式允许的字段内选择。 |
| HTTP缓存 | 直接映射到资源标识符、验证器和缓存元数据。 | 通常需要操作感知的规范化、持久查询或客户端缓存。 |
| 错误 | 通常通过HTTP状态加应用程序错误主体来表达。 | 可以返回带有错误列表和空值传播的部分数据。 |
| 版本演变 | 可以使用媒体类型、头部、路径或附加表示变化。 | 通常倾向于附加模式演变和字段弃用。 |
| 需求控制 | 端点、方法和负载规则约束了许多操作。 | 深度、广度、字段成本、分页和解析器行为需要明确控制。 |
每种方法的优势所在
当其属性解决特定工作流约束时，REST API与GraphQL的区别和决策指南在设计中有一席之地。以下场景将该概念与可观察的工程需求联系起来。
稳定资源的REST
公共的、可缓存的资源以及简单的CRUD-like交互从直接的HTTP语义和广泛的基础设施支持中受益。
复合客户端的GraphQL
需要不同嵌套数据形状的接口可以通过类型字段选择减少客户端协调。
文件和协议语义的REST
下载、重定向、条件请求、范围和内容协商适合既定的HTTP行为。
领域图的GraphQL
多个产品客户端之间共享的关系可以通过一个可发现的模式进行公开。
按约束而不是时尚选择
当领域与资源的映射清晰，HTTP缓存有价值，交互通过标准语义易于理解，并且客户端接受服务器定义的表示时，请选择REST。REST还适合那些消费者需要简单检查、命令行访问和成熟网关策略的公共API。
当几个第一方客户端需要不同但相关的数据形状，类型模式可以成为共享的产品契约，并且团队可以操作解析器性能、查询成本、模式治理和GraphQL感知的可观察性时，请选择GraphQL。只有在服务器能够限制和解释其成本时，客户端的灵活性才有用。
在声称性能获胜之前，请测量一个代表性的工作流。 HTTP缓存规范 解释了HTTP响应的重用，而GraphQL规范定义了执行而不是缓存架构。比较实际操作的总传输字节数、依赖的往返次数、服务器工作、缓存命中行为、尾延迟和故障处理。
导致不良迁移的弱比较
- REST总是过度获取数据。 设计良好的REST API可以提供集中资源、稀疏字段、嵌入关系或特定目的的表示。
- GraphQL总是需要一个请求。 客户端仍然可以发出多个操作，订阅或文件传输可以使用单独的通道。
- GraphQL具有自动授权。 模式验证结构；应用策略仍然必须授权字段、对象和操作。
- REST需要URL版本控制。 兼容性可以通过表示、头、增量变化和明确的弃用政策进行管理。
- 一种风格必须取代另一种。 增量采纳或分隔边界通常降低风险并保持现有系统的优势。
迁移与共存模式
GraphQL层可以聚合现有的REST服务，但不应逐字段复制它们的端点。构建一致的领域模式，批量下游读取，保持源授权，并以故意的可为空性暴露下游故障。对图操作和触发的REST调用进行仪器化。
REST外观可以公开受图支持的稳定任务或资源工作流。这可以帮助需要可预测HTTP语义的外部消费者，而内部客户端保持更丰富的图选择。外观应拥有其表示契约，而不是通过REST形状的URL传递任意的GraphQL文档。
在迁移期间，运行等效操作并排进行并比较正确性，然后比较速度。验证标识符、授权、分页、空值处理、错误含义、缓存行为和可观察性。一次迁移一个受限工作流，并保持一个回滚边界，不要求消费者保持同步变化。
REST API与GraphQL的区别和决策指南审查清单
使用这些检查将REST API与GraphQL的区别和决策指南定义转化为实施证据，以便开发者、运营商或审查者可以复现。
- 重新阐述边界。 对于REST API与GraphQL的区别和决策指南，识别调用者、提供者、路径和标记完整结果的确切事件。
- 验证中心声明。 用实现及其文档确认这一陈述：REST和GraphQL定义了不同的接口形状。REST围绕资源和表示组织交互；GraphQL针对类型模式执行选择。
- 追踪机制。 观察REST资源交互、GraphQL选择执行、操作结果，并记录哪一组件拥有每个阶段。
- 检查最近的区别。 文档化为什么主契约在该系统中意味着“资源、表示、方法、媒体类型和链接”。
- 测试一个典型用例。 对具有现实数据、位置、体积和权限边界的稳定资源使用REST。
- 防止已知错误。 查看“REST总是过多获取。”并添加接受检查以捕捉它。
- 限制工作负载。 为REST API与GraphQL设置主题适当的限制：差异和决策指南，包括适用时的有效载荷、并发、执行时间和存储输出。
- 记录决定。 解释为什么REST API与GraphQL：差异和决策指南适合这个边界，并说明稍后会证明不同方法的证据。
结论
REST API与GraphQL：差异和决策指南应描述设计中可测试的部分，而不是作为相邻行为的松散标签。审查应保留此中心决定：REST和GraphQL定义不同的接口形状。REST围绕资源和表示组织交互；GraphQL根据类型化模式执行选择。它还应防止REST总是过多获取，并保持REST API与GraphQL：差异和决策指南在接口或网络的记录政策范围内。
准备好构建您的Web数据工作流程了吗？
将测量的REST API与GraphQL：差异和决策指南获取或集成步骤连接到上述描述的验证和存储实践。
今天注册并获得 $5免费信用 — 无需信用卡.
索取您的$5信用→常见问题
GraphQL比REST快吗？
GraphQL本身并不比REST快。它可以减少传输的字段或依赖客户端的往返次数，而解析器的分发和有限的共享缓存可能会增加服务器工作。在代表性负载下测量完整操作。
REST和GraphQL可以使用相同的后端吗？
是的。两者都可以调用相同的应用服务、数据库和缓存。重要的区别在于呈现给客户端的接口和执行模型，而不是其背后的存储系统。
哪个更容易缓存？
REST通常与HTTP缓存更直接对齐，因为资源标识符和响应元数据对通用基础设施是可见的。GraphQL可以使用标准化的客户端缓存、持久化操作和网关缓存，但策略更依赖于操作。
公共API应该使用REST还是GraphQL？
答案取决于消费者需求、领域形状、工具预期、缓存、安全控制和运营成熟度。REST通常更简单，适合广泛的公众消费；当消费者重视类型灵活选择而提供方可以管理时，GraphQL可以很好地工作。