理解请求与处理成本
示例采用虚构架构，实际API中必须存在customer、orders和total。一条请求可能触发多次服务器读取。REST也能提供定制响应。单一HTTP端点在GraphQL中常见，但并非所有架构的强制要求。
query RecentOrders($id: ID!) {
customer(id: $id) {
name
orders(first: 5) {
nodes { id total }
}
}
}用代表性任务比较
- 在相同界面、权限和实际数据量下测量字节数、延迟、错误与服务器工作量。
- 检查分页、减少N+1的批量读取、缓存策略及账号间的数据隔离。
- 评估架构演进、旧客户端兼容性与运维负担。保留REST可能更简单。
实施权限与负载限制
先验证身份，再在业务逻辑中授权对象与字段。限制列表大小、深度、别名、批量操作和估算成本；请求频率本身不能代表负载。隐藏内省并不能取代这些控制，还应测试拒绝访问和部分响应。
一手资料
管理 GraphQL 模式和查询成本。
GraphQL 允许客户端选择字段，但这种灵活性需要对对象和字段进行授权。仅设置大小或深度上限并不能替代对查询工作量的衡量。
- 测试敏感字段和其他帐户拥有的对象。
- 限制并观察服务的成本、深度和请求量。
- 版本控制模式变更并测试旧客户端。
一手资料：OWASP — GraphQL Cheat Sheet. 相关方法：阅读实用指南.
ETag、HTTP 缓存与并发更新
此语言版本的详细参考说明以英语提供。
REST and GraphQL: separate representation and authorisation
An HTTP ETag applies to a selected representation. It is neither permission for every returned object nor a universal consistency contract for GraphQL entities.
- Define which response variants have their own validators.
- Test object and field access independently from HTTP conditions.
- Do not automatically apply the PUT scenario to a GraphQL mutation; specify its concurrency contract.
Explore ETag comparisons and the simulator →
References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3