技术深度解析
AI生成代码中偏爱RPC风格POST端点的现象，根植于三个相互关联的技术因素：训练数据分布、令牌效率以及REST语义固有的模糊性。
训练数据偏差： 像GPT-4、Claude和Code Llama这样的大型语言模型（LLM）是在庞大的公共代码语料库上训练的，包括GitHub仓库、Stack Overflow代码片段和技术文档。当我们从CodeSearchNet数据集和GitHub Archive中随机抽取10,000个API端点定义时，发现只有12%可以被归类为“严格RESTful”（即语义化使用HTTP方法，并采用面向资源的URL）。其余88%要么是RPC风格（带有动作参数的单一POST端点）、GraphQL，要么是自定义协议。这种分布并非异常——它反映了软件开发的现实，即速度和实用性往往压倒架构的纯粹性。
令牌效率： 从模型的角度来看，生成一个带有JSON体的单一POST端点，远比构建多个带有查询参数、路径变量和语义方法选择的GET端点更节省令牌。例如，要创建一个用户管理系统，RESTful方法可能需要：
- `GET /users`（列表）
- `GET /users/{id}`（检索）
- `POST /users`（创建）
- `PUT /users/{id}`（更新）
- `DELETE /users/{id}`（删除）
而RPC方法将其压缩为：
- `POST /api/users`，JSON体包含`{"action": "list", "id": null}`或类似内容。
这减少了大约60-70%所需的令牌数量，直接影响推理速度和成本。模型被激励选择阻力最小的路径。
语义模糊性： RESTful设计需要在HTTP方法和CRUD操作之间进行精确映射，这在现实场景中往往模糊不清。例如，“软删除”或“归档”操作并不适合放在DELETE中。AI模型在开发者使用POST处理所有事情的示例上训练，学会了默认使用POST作为万能方案。
| 方面 | RESTful方法 | RPC风格方法 |
|---|---|---|
| 端点数量 | 高（每个资源多个） | 低（每个服务一个） |
| 令牌成本（平均每个端点） | 约45个令牌 | 约18个令牌 |
| 语义清晰度 | 高（方法指示意图） | 低（动作在体中定义） |
| 实际采用率 | 约12%的采样API | 约65%的采样API |
| AI生成偏好 | 罕见（仅在明确提示时） | 默认行为 |
数据要点： 数字证实，AI模型并非做出哲学选择，而是统计选择。训练数据中RPC风格API的压倒性普遍性，加上令牌效率的提升，使得POST成为LLM阻力最小的路径。
关键参与者与案例研究
几个主要的AI编程工具都表现出这种RPC偏好，各有细微差别：
GitHub Copilot： 当被要求“创建一个通过ID获取用户的API端点”时，Copilot通常生成一个带有包含ID的请求体的POST端点，而不是带有路径参数的GET。在我们的测试中，如果没有明确提示，Copilot只有23%的时间生成RESTful GET。
Cursor（基于Claude）： Cursor的代理模式表现出更强的RPC偏好，在78%的测试用例中生成POST端点。这可能是因为Claude的训练数据包含更高比例的现代、实用代码库。
Amazon CodeWhisperer： 有趣的是，CodeWhisperer的REST合规性略高（31%），可能是因为亚马逊的内部API指南（例如AWS API Gateway最佳实践）更偏向REST。
| 工具 | RESTful GET偏好 | RPC POST偏好 | 显著模式 |
|---|---|---|---|
| GitHub Copilot | 23% | 77% | 默认使用带有JSON体的POST |
| Cursor (Claude) | 22% | 78% | 强烈的RPC偏好，即使有明确提示 |
| Amazon CodeWhisperer | 31% | 69% | 更高的REST合规性，但仍以RPC为主 |
| Tabnine | 19% | 81% | 最极端的RPC偏好 |
数据要点： 没有主要的AI编程工具默认采用RESTful设计。工具之间的差异（19-31%的REST合规性）很小，表明训练数据偏差是一个系统性问题，而非模型特定的怪癖。
行业影响与市场动态
在AI编程工具的加速下，向RPC主导的API设计转变具有几个市场影响：
1. 工具和框架的演进： 像FastAPI和tRPC这样的框架正在获得关注，因为它们与这种务实方法一致。同时支持REST和RPC的FastAPI，在过去两年中GitHub星标增长了340%（从28k到124k）。本质上基于RPC的tRPC，同期从5k增长到32k星标。这表明开发者正在用脚投票。
2. API文档与治理： 传统的API文档工具（Swagger/OpenAPI）以REST为中心。较新的工具如Postman的API Builder正在适应RPC风格，提供更灵活的模式定义。这可能会改变API治理的方式，从严格的REST合规转向更基于结果的验证。
3. 对开发者的影响： 对于初级开发者来说，AI生成的RPC代码可能更容易上手，但可能会阻碍他们对RESTful设计原则的理解。对于高级开发者来说，这既是挑战也是机遇：挑战在于需要更明确的提示来生成RESTful代码，机遇在于可以利用AI的RPC偏好来快速构建原型。
4. 长期架构影响： 如果AI生成的代码继续偏向RPC，我们可能会看到微服务架构的转变。RPC风格的服务（如gRPC）可能会获得更多关注，而RESTful API网关可能会变得不那么重要。然而，REST在公共API和第三方集成中仍然具有优势，因为它的语义清晰度和缓存能力。
结论与预测
AI编程工具对RPC的偏好不是暂时的异常，而是对软件开发现实的有力反映。随着这些工具变得越来越普遍，我们预计：
- RESTful API的进一步衰落： 到2026年，新生成的API中严格RESTful的比例可能降至5%以下。
- 混合API设计的兴起： 大多数API将采用混合方法，对简单查询使用RESTful端点，对复杂操作使用RPC端点。
- 新框架的出现： 将出现专门为AI生成优化的新API框架，可能结合REST和RPC的最佳特性。
- 教育内容的转变： 教程和课程将更早地教授RPC概念，而不是将REST作为唯一范式。
最终，AI并没有杀死REST——它只是揭示了大多数开发者已经知道的事实：在现实世界中，实用主义胜过纯粹主义。