Revel框架设计RESTful API需显式声明路由、按HTTP动词命名控制器方法（如GetUsers）、手动设置状态码与响应格式，并严格使用名词复数路径；漏掉任一环节将导致语义错乱或404。
Revel 框架写 API 不是“开箱即用”的 RESTful 模板，而是靠显式路由 + 命名约定 + 手动状态码控制来实现——漏掉任一环，接口就容易返回 200 却语义错乱，或 404 却找不到原因。
控制器方法名必须严格匹配 HTTP 动词 + 资源名
Revel 不识别 GetUserById 或 createOrder 这类命名。它只认标准前缀 + 首字母大写的资源名：
-
GetUsers→ 对应GET /users（列表） -
GetUser→ 对应GET /users/:id（单条） -
PostUser→ 对应POST /users（创建） -
PutUser→ 对应PUT /users/:id（全量更新） -
DeleteUser→ 对应DELETE /users/:id
常见错误：postUser（小写 p）、UpdateUser（Revel 不绑定 UPDATE）、GetUserList（不匹配默认路由规则）都会导致 404。
routes 文件里必须一行行写死路由，不能省
Revel 没有 Route::apiResource() 或自动扫描机制。所有路径都得在 conf/routes 中显式声明：
GET /users Application.GetUsers GET /users/:id Application.GetUser POST /users Application.PostUser PUT /users/:id Application.PutUser DELETE /users/:id Application.DeleteUser
注意两点：
-
:id必须带冒号，且不能写成{id}或<id></id>（Revel 只认:param形式） - PATCH 不被默认支持，要加部分更新需额外加一行：
PATCH /users/:id Application.PatchUser，并确保PatchUser方法存在
状态码和响应体必须手动设置，别信默认值
c.RenderJSON() 默认返回 200，但 RESTful 要求：
- 创建成功 →
c.Response.Status = 201+c.RenderJSON(user) - 删除成功 →
c.Response.Status = 204+return nil（不返回 body） - 资源不存在 →
c.Response.Status = 404+c.RenderJSON(map[string]string{"error": "not found"}) - 参数校验失败 →
c.Response.Status = 400，别用RenderError（它固定返回 500）
容易忽略的点：Revel 的 JSON 响应默认不带顶层包装（如 {"data": {...}}），如果前端强依赖统一结构，得自己封装 map 再传给 RenderJSON。
参数来源要分清：Route、Query、Body 各走各的路
Revel 把不同来源的参数都塞进 c.Params，但取法不同：
- 路径参数（如
/users/:id中的id）→c.Params.Get("id") - 查询参数（如
?page=2&limit=10）→c.Params.Get("page")（不是c.Params.Route.Get） - 请求体（JSON）→ 用
json.Unmarshal(c.Request.Body, &user)，Revel 不提供自动绑定
别指望 c.Params.Get("page") 能同时拿到路径和查询参数——它优先取 Route 参数，冲突时后者会被忽略。真要混用，得显式调 c.Params.Query.Get("page")。
最常被绕过的细节是：Revel 的 Controller 方法签名固定，无法像 Gin 那样用 c.ShouldBindJSON(&user) 一键解析；所有 JSON 解析、字段校验、错误映射都得手写，否则空指针 panic 或静默失败会直接落到日志里，而不会返回友好提示。
