构建REST API时添加大量输入验证致代码冗余，是否为良好实践？

一、单API调用包含多验证是合理且必要的实践 #

API输入验证是保障数据一致性、后端安全性的核心环节，你列出的这些验证（数据类型校验、非空检查、格式合规性、数据库唯一性校验）都是后端必须做的前置检查——既能有效避免脏数据进入数据库，减少后续业务逻辑的异常处理负担，还能快速给客户端明确的错误反馈，所以这不是过度设计，是标准的良好实践。

二、解决代码冗余、提升可读性的方案 #

你遇到的代码冗余问题，核心是验证逻辑没有结构化管理，试试以下优化方式：

1. 用验证框架统一管理规则 #

别手写重复的if-else判断，用对应语言的验证框架把规则集中定义：
比如Python用Pydantic、Java用Jakarta Validation、Node.js用Joi，以Python为例：

from pydantic import BaseModel, EmailStr, field_validator
import re

class CustomerInput(BaseModel):
    id: int
    customer_id: int
    firstname: str
    lastname: str | None
    contact: str
    email: EmailStr
    created_time: str
    updated_time: str

    @field_validator("firstname")
    def check_firstname_not_empty(cls, value):
        if not value.strip():
            raise ValueError("firstname不能为空")
        return value
    
    @field_validator("contact")
    def check_contact_is_numeric(cls, value):
        if not re.fullmatch(r"\d+", value):
            raise ValueError("contact必须为纯数字")
    
    @field_validator("created_time", "updated_time")
    def check_time_not_empty(cls, value):
        if not value.strip():
            raise ValueError("时间字段不能为空")

所有验证规则集中在一个模型里，不用散落在业务代码中，可读性和维护性直接提升。

2. 把数据库唯一性校验封装成独立逻辑 #

将email、contact的存在性检查抽成单独的工具函数或服务方法，避免重复写查询逻辑：

def check_email_exists(db_session, email: str) -> bool:
    return db_session.query(Customer).filter(Customer.email == email).first() is not None

def check_contact_exists(db_session, contact: str) -> bool:
    return db_session.query(Customer).filter(Customer.contact == contact).first() is not None

在业务流程中直接调用这些函数即可，不用每次都写完整的数据库查询语句。

3. 分层处理验证逻辑 #

把验证拆成两层，各司其职：

• 基础格式验证：在请求入口（如Controller层）通过验证框架完成，快速拦截明显的非法输入；
• 业务规则验证：在Service层调用封装好的业务检查方法，处理和数据库、业务规则相关的验证。

三、兼顾统一响应结构与差异化错误反馈 #

可以通过「自定义异常+全局异常处理器」的方式实现：

1. 先定义统一的响应结构，比如：

{
  "code": "VALIDATION_ERROR_FIRSTNAME_EMPTY",
  "message": "名字不能为空",
  "details": null
}

2. 针对不同验证失败场景抛出自定义异常，比如EmailExistsError、ContactExistsError、EmptyFirstnameError等；
3. 在全局异常处理器中捕获这些异常，映射到对应的错误码和提示信息，返回统一格式的响应。

这样既保持了响应结构的一致性，又能给客户端明确的错误原因，方便前端针对性处理。

内容的提问来源于stack exchange，提问作者Unnikrishnan KJ