Go实现REST API核心在于路由语义、HTTP方法映射与错误响应一致性；生产推荐gin/echo而非net/http，因其自动处理路径参数、中间件、Content-Type及JSON编解码，避免重复样板代码。
Go 语言实现 REST API 接口，核心不在“能不能”，而在「路由设计是否符合资源语义」「HTTP 方法是否被正确映射」「错误响应是否可预测」。用 net/http 能写，但生产环境建议用 gin 或 echo——它们默认处理了 Content-Type 自动推导、中间件链、路径参数提取等琐碎逻辑。
为什么不用标准库 net/http 直接写路由
标准库太底层：没有内置的路径参数解析（如 /users/:id），404/405 错误要手动判断，JSON 序列化/反序列化要反复写 json.Marshal/json.Unmarshal + 错误检查，且无统一错误响应格式。容易写出大量重复样板代码。
- 你得自己解析
r.URL.Path并做字符串切分才能拿到id -
http.ServeMux不支持通配符路径，/posts/:id这类写法必须靠第三方路由器（如gorilla/mux）补足 - 没有中间件机制，鉴权、日志、CORS 都得在每个 handler 里手写
用 gin 实现标准 REST 资源路由
gin 的 GET/POST/PUT/DELETE 方法名直接对应 HTTP 动词，路径中 :id 会被自动绑定为参数，c.ShouldBindJSON() 封装了反序列化+校验逻辑。
package main
import (
"github.com/gin-gonic/gin"
)
type User struct {
ID uint `json:"id"`
Name string `json:"name"`
}
var users = []User{{ID: 1, Name: "Alice"}}
func main() {
r := gin.Default()
// GET /users → 列表
r.GET("/users", func(c *gin.Context) {
c.JSON(200, users)
})
// GET /users/:id → 单个
r.GET("/users/:id", func(c *gin.Context) {
id := c.Param("id") // 自动提取 :id 段
// 实际应查 DB，此处简化
c.JSON(200, User{ID: 1, Name: "Alice"})
})
// POST /users → 创建
r.POST("/users", func(c *gin.Context) {
var u User
if err := c.ShouldBindJSON(&u); err != nil {
c.JSON(400, gin.H{"error": err.Error()})
return
}
users = append(users, u)
c.JSON(201, u)
})
// PUT /users/:id → 全量更新
r.PUT("/users/:id", func(c *gin.Context) {
id := c.Param("id")
c.JSON(200, gin.H{"message": "updated", "id": id})
})
r.Run(":8080")
}
REST 接口设计最容易被忽略的三件事
很多人只关注“能跑”，但线上服务崩溃常源于这三点没对齐：
立即学习“go语言免费学习笔记（深入）”；
-
404和405必须区分：资源不存在返回404 Not Found，方法不支持（如对/users发PUT）返回405 Method Not Allowed；gin默认会帮你设405，但404需你主动检查数据是否存在并调c.AbortWithStatus(404) - 请求体校验不能只靠
ShouldBindJSON：它只检查 JSON 格式和字段类型，业务规则（如Name非空、Email格式）要用结构体 tag 加binding:"required,email"，否则前端传空字符串你也照收 - 不要在响应里暴露内部错误细节：数据库连接失败、SQL 语法错这类信息绝不能原样返回给客户端，应统一转成
500 Internal Server Error+ 可读提示（如{"error": "failed to save user"}），真实错误记日志即可
真正难的不是写完一个 GET /users，而是让所有接口在状态码、错误结构、分页格式、时间字段序列化（如用 RFC3339）、空值处理上保持一致。这些细节堆起来，才叫「可用的 REST API」。
