REST缺乏部分批量处理能力时的变通设计与GraphQL替代

REST一个被普遍认可的真实短板是缺乏对资源”部分获取”和”批量处理”的原生 支持。部分获取问题：只想拿用户姓名，RPC可以设计一个精确返回字符串的 getUsernameById，REST却只能请求整个用户对象再丢弃多余字段，造成”过度 获取”（Overfetching）——根源是HTTP协议本身没有对请求资源的结构化描述 能力。批量处理问题：给一个用户名字加”VIP”前缀可以用一次PUT解决，但给 1000个用户批量加前缀，若真发1000次PUT会触发429 Too Many Requests，只能 被迫设计一种抽象的”任务资源”（如VIP-Modify-Task），把1000个ID交给这个 任务来驱动执行；类似地，下单-冻结库存-支付-加积分这类跨多资源的流程， 也常需要发明”结算单”这样的资源来贯穿整个过程。这两个短板本质是同一个 原因：面向资源的抽象把”数据”当主体、”操作”收敛成统一接口，天生不擅长 描述跨资源的复杂流程。GraphQL被认为是理论上更优的替代方案（同样面向 资源但有自己的查询协议，能精确描述要拿哪些字段），但代价是脱离了HTTP， 重新面临”如何推广交互接口”这个几乎所有RPC框架都要面对的老问题。