在上一篇中，我们讨论了如何在RESTful API中使用JWT进行认证与授权，本篇将重点关注错误处理中的错误代码与状态码的设计。为了构建一个更好的API，理解和使用合适的错误代码与状态码是至关重要的，这有助于开发者和用户快速识别和解决问题。

状态码概述

HTTP状态码是由服务器返回的三位数字，用于指示请求的处理结果。状态码通常分为五个类别：

• 1xx (信息性状态码): 表示请求已被接受，继续处理。
• 2xx (成功状态码): 表示请求已成功处理，如200 OK。
• 3xx (重定向状态码): 表示请求的资源已移动，如301 Moved Permanently。
• 4xx (客户端错误状态码): 表示请求有错误，客户需要修正，如404 Not Found。
• 5xx (服务器错误状态码): 表示服务器在处理请求时出错，如500 Internal Server Error。

选用状态码的最佳实践

在设计RESTful API时，适当地使用状态码可以帮助调用方理解发生了什么。以下是一些常见状态码的使用场景和建议：

200 OK

用在请求成功的情况下。

GET /api/users/1 HTTP/1.1
200 OK
复制

201 Created

用来表示成功创建了资源。

POST /api/users HTTP/1.1
201 Created
Location: /api/users/2
复制

400 Bad Request

当请求参数错误时，返回此状态码。

POST /api/users HTTP/1.1
400 Bad Request
复制

401 Unauthorized

表示请求未通过认证，需提供JWT或其他认证信息。

GET /api/protected HTTP/1.1
401 Unauthorized
复制

403 Forbidden

用户经过身份验证，但没有权限访问资源。

GET /api/admin HTTP/1.1
403 Forbidden
复制

404 Not Found

请求的资源不存在。

GET /api/users/99999 HTTP/1.1
404 Not Found
复制

500 Internal Server Error

请求的处理过程中发生了服务器错误。

GET /api/users HTTP/1.1
500 Internal Server Error
复制

错误代码的设计

除了使用HTTP状态码外，设计统一的错误代码也是提升API可用性的重要一环。错误代码通常是一个字符串或数字，能够提供更具体的错误信息，帮助开发者快速定位问题。

错误代码示例

以下是一些建议的错误代码及其含义：

错误代码	含义
USER_NOT_FOUND	用户未找到
INVALID_PARAMETER	无效的请求参数
UNAUTHORIZED_ACCESS	未授权的访问
RESOURCE_EXISTS	资源已存在

示例代码

在Node.js中，我们可以扩展错误处理的逻辑，比如：

app.post('/api/users', (req, res) => {
    const { username } = req.body;
    
    if (!username) {
        return res.status(400).json({
            status: 'error',
            errorCode: 'INVALID_PARAMETER',
            message: 'Username is required'
        });
    }
    
    // 假设这是一个重复用户检查
    const userExists = checkIfUserExists(username);
    if (userExists) {
        return res.status(409).json({
            status: 'error',
            errorCode: 'RESOURCE_EXISTS',
            message: 'User already exists'
        });
    }

    // 创建用户的逻辑...
    res.status(201).json({
        status: 'success',
        userId: newUserId
    });
});
复制

总结

在设计RESTful API时，正确使用HTTP状态码与自定义错误代码可以显著提升用户和开发者的使用体验。状态码提供了对请求处理结果的快速反馈，而错误代码则可以帮助开发者更深入地理解问题的原因。在接下来的篇章中，我们将继续探讨如何统一错误响应格式，这将使得错误处理更加规范化和易于管理。