随着互联网应用的不断发展，Web API（应用编程接口）的作用越来越重要。而在 API 的设计中，RESTful 架构已经成为了常见的选择。RESTful 的优点包括可读性好、易于拓展、容易缓存等，但是错误处理是一个常见的问题。
正确地使用和定义错误码是实现良好 RESTful API 的重要组成部分。本文将会介绍 RESTful API 中错误码的定义和使用方法，并提供一些示例代码。
错误码的作用和设计原则
RESTful API 的错误码旨在向客户端（例如 Web 应用程序或移动应用程序）提供有关错误原因的信息。错误码应该根据以下设计原则来设计：
可读性
错误码应该易于记忆和理解，因此可以提供有关错误的基本信息。例如，“404 Not Found”是一个普遍的错误码，指示请求的资源不存在。
规范性
RESTful API 的错误码应该符合标准的 HTTP 错误码。这有助于客户端开发人员更容易地理解错误。常见的 HTTP 错误码请参见以下表格：
| HTTP 错误码 | 错误描述 |
|---|---|
| 400 | 请求的语法错误。 |
| 401 | 请求未授权。 |
| 403 | 请求被拒绝。 |
| 404 | 请求的资源不存在。 |
| 405 | 请求的方法不允许。 |
| 406 | 无法根据客户端请求的内容特性完成请求。 |
| 500 | 服务器内部错误。 |
一致性
错误码应该在所有的请求中保持一致，并且应该与所要传递的信息一致。例如，“404 Not Found”错误码应该表示同一种错误，并且不能表示不同种类的错误。
可扩展性
RESTful API 的错误码应该是可扩展的。如果需要添加新的错误码，它们应该被设计为不冲突，不重复，并且能够提供额外的信息。
确定错误码的场景
在确定错误码时，我们需要考虑的是不同种类的错误场景。以下是一些常见的错误场景：
无效的身份验证信息
很多 RESTful API 都要求身份验证，因此无效的身份验证信息可能会导致错误。应该为此类错误定义“401 Unauthorized”错误码。
无效的参数
如果客户端提交了无效的参数，API 应该返回“400 Bad Request”错误码。 API 应该在返回“400 Bad Request”错误码时包含一个 JSON 对象，其中包含有关所发生错误的详细信息。
无法找到资源
如果客户端尝试访问不存在的资源，API 应该返回“404 Not Found”错误码。返回的错误消息应该向客户端明确说明请求的资源不存在。
无权限
如果客户端试图访问其没有权限的资源，API 应该返回“403 Forbidden”错误码。这种情况通常建议返回一个 JSON 对象，在消息中包含有关错误的详细信息。
定义错误码
RESTful API 中的错误码通常由服务器返回，以便客户端可以更好地处理 HTTP 响应。为了定义错误码，请在响应中设置“状态码”和以下属性：
- “error”（必须），这是一个描述错误的字符串。
- “message”（可选），这是额外信息的字符串。
- “moreInfo”（可选），这是一个 URL，其中包含有关错误的更多信息。
以下是返回错误码的示例代码：
{
status: 401,
error: 'Unauthorized',
message: 'Authentication failed due to invalid credentials',
moreInfo: 'http://server.com/errors/401.html'
}处理错误
在客户端的代码中，必须处理 RESTful API 的错误。以下是基本的处理错误的代码示例（使用 fetch API）：
-- -------------------- ---- -------
------------------
-------------- -- -
-- -------------- -
----- ---------------------------
-
------ ----------------
--
---------- -- -
-- ----
--
---------- -- -
-- ----
---总结
在设计 RESTful API 时，错误处理应该是必须考虑的一部分。错误码应该由服务器返回，并应该遵循上述设计原则。此外，客户端应该能够检测并处理 RESTful API 中的错误，以便在需要时提示用户。
来源：JavaScript中文网 ，转载请注明来源 https://www.javascriptcn.com/post/649d45d348841e9894a051a9