构建 REST API 时，我必须使用状态代码吗？

Question

我正在开发一个具有后端 API 的 Web 应用程序，该应用程序将主要由参考前端应用程序使用，但其他客户端也可以使用它。

我的 API 发送的数据具有特定的类型结构。我正在使用 Rust 的类型系统，该系统具有枚举，其选项中可能包含其他数据。例如，检索文章的路由的响应可以建模为：

#[derive(serde::Serialize)]
#[serde(tag = "status")]
enum ArticleGetResult {
  Exists {
    name: String,
    content: String,
    score: i32,
  },
  NotFound,
  Redirected {
    new_id: usize,
  },
  DatabaseError {
    error_text: String,
  }
}

在 API 中提供有用的状态代码以及标头被认为是一种很好的形式，并且后端会在适用时发送这些内容。但是，由于技术原因，在前端代码中访问这些内容有些困难，因此我只使用响应正文并忽略状态代码和标头。

-> GET /articles/1
<- 200 OK
{"status": "Exists", "name": "Article", "content": "article content", "score": 5}

-> GET /articles/2
<- 404 Not Found
{"status": "NotFound"}

-> GET /articles/3
<- 301 Moved Permanently
Location: /articles/4
{"status": "Redirected", "new_id": 4}

-> GET /articles/4
<- 500 Internal Server Error
{"status": "DatabaseError", "error_text": "some error happened"}

在客户端代码中不使用状态代码和标头信息而仅使用响应正文的信息是否有任何特殊的缺点？

Answer 1

状态码是HTTP协议不可或缺的一部分，它们在REST API中发挥着至关重要的作用。它们为服务器提供标准化方法来传达客户端请求的结果。协议的第一个版本（HTTP 1.0）中不存在状态代码和标头，但添加它们是为了提供标准和良好的实践。在项目中遵循约定可以减少其他开发人员的困惑，并且更容易开发客户端。当你的

status

出现在你的身体中时，你就在重新发明一个轮子，而它已经根本不是 RESTful API 了。对这样的 API 进行版本控制并遵循特定的契约比较困难，您必须使客户端代码更加复杂才能为所有状态情况提供特定的枚举，而不是使用所有现代框架中提供的方式。另外，您确定可以以正确的方式实现无状态性和可缓存性吗？您甚至可能会失去浏览器提供的缓存和优化的机会，更不用说解决方案的安全性了。你能以正确的方式进行错误处理吗？有很多这样的问题使得标准比用你自己的重新发明轮子更好。