外键约束违反应该视为客户端错误吗？若是，应该采取何种处理方式？

当应用程序遇到外键约束违规时，应该将其视为客户端错误，因为这是由用户输入不正确数据引起的。建议将客户端错误和服务器错误移动到另一个包中，以避免循环依赖。对于外键违规，HTTP 422 - UNPROCESSABLE ENTITY 状态代码可能更合适，因为它表示请求不正确，即使它按照正确的语法发出。然而，许多 API 只是返回 HTTP 400 - BAD REQUEST，并提供错误描述，而不区分具体错误类型。

我正在尝试以一种务实的方式来处理与我的 web 应用程序中的客户端输入相关的数据库错误。例如，如果我发现外键违规，我不认为应该是 500，因为用户提供了不正确的数据。我还想返回客户端请求中的哪个字段导致外键违规（另一种情况可能是唯一约束）。到目前为止，我提出的所有解决方案都会导致我的 db 包依赖于 net/http 包或我自己的 http 处理程序包。

这是我的代码的简化示例：

// this implements an interface that's omitted for brevity
type ClientError struct {
    Code       int
    LogMessage string
    LogRequest *http.Request
    Body       interface{}
}

// this implements an interface that's omitted for brevity
type ServerError struct {
    LogType    string
    LogMessage string
    LogRequest *http.Request
}

// in my http handler package
func (h *ApiHandler) PostSomething(c *gin.Context) {
    // request parsing omitted for brevity

    // insert the review media metadata into the database. the location owns the media
    err := h.db.InsertRecord(parsedRequest)
    if err != nil {
        // if we didn't account for the error, it's an internal error
        if errors.Is(err, cerrors.ErrUnknown) {
            c.Error(ServerError{"db", err.Error(), c.Request})
            return
        }
        // otherwise, this function catches invalid data from the client
        c.Error(ClientError{
            Code:       http.StatusBadRequest, // what if I wanted to return other 4xx based on my db logic?
            LogMessage: "failed insert",
            LogRequest: c.Request,
            Body:       someObject,
        }).SetType(gin.ErrorTypePublic)
        return
    }

    c.Status(http.StatusCreated)
}

// in my db package
func (db *DB) InsertRecord() error {
    // some insert statement, and scan the result
    var result someVariable
    if err := row.Scan(&result); err != nil {
        if pqErr, ok := err.(*pq.Error); ok {
            // foreign key violations
            c := pqErr.Constraint
            if c == "unq_violation" { 
                return ErrUnqViolation // ex: handled as a 409
            } else if c == "fk_some_fk" {
                return ErrFkSomething // ex: handled as a 400
            } else {
                return ErrUnknown
            } 
            // etc. for example, what if I wanted to return various 4xx 
            // or is this a bad idea in general

        }
    }
}

// note: using the gin framework, I also have some middleware that does some logging
// based on ClientError vs. ServerError

注意：我在这里获得了错误处理的灵感

如何从我的数据库处理程序中干净地返回基于 http 的错误，例如 400 或 409，而不依赖于 http 包，并且在我的 http 处理程序中没有针对每个数据库错误类型的 if 语句（即将所有 4xx 分组）错误归为一类）？我是否应该将 clienterror 和 servererror 移动到另一个包（以避免循环依赖）并直接从我的 db 包返回 client/servererror ，还是耦合不良？

解决方案

如果该违规源自客户端请求（例如向 REST 端点发出 POST），则它应该是客户端错误。服务器错误应保留为诸如错误代码或故障基础设施之类的错误。

没有严格的规则来确定适当的 HTTP 响应状态代码。 HTTP 409 - CONFLICT 通常被保留以指示某种重复（例如发布违反 UNIQUE 约束的数据），这可能适用也可能不适用，具体取决于您所说的“外键违规”的含义。如果您的意思是“外键值不对应于任何实体 id”，则状态代码 HTTP 422 - UNPROCESSABLE ENTITY 对我来说更合适。

这只是一个约定，许多 API 甚至不区分这些细节，只是返回 HTTP 400 - BAD REQUEST 以及错误描述，即使在语义上使用它（按照约定）发出的请求是不正确的使用正确的语法。

理论要掌握，实操不能落！以上关于《外键约束违反应该视为客户端错误吗？若是，应该采取何种处理方式？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！