外键违规是否应该是客户端错误？如果是，应该如何处理？

Question

我正在尝试以一种务实的方式来处理与我的 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到另一个包（以避免循环依赖）并Client/ServerError直接从我的 db 包返回，还是耦合不好？

Answer 1

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

\n\n

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

\n\n

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

\n