RESTful 的增删改查成功应该返回什么状态码?

[Vimax]

RESTful 的 GET POST PUT DELETE 如果操作成功应该返回什么状态码呢?

用 200,201,202,204 代表 4 种请求的成功合适吗?

请求成功

• GET 200 OK
• POST 201 Created
• PUT 202 Accepted
• DELETE 204 No Content

如果 GET POST PUT 　 DETELE 请求,数据库执行结果都为 0.又如何返回 HTTP 状态码呢?

是返回 404 not found 吗?

另外一个问题

请求方式的数据类型: GET 和 DELETE 是否[不能]或[不推荐]使用 JSON 数据的形式.

前端使用的是 VUE axios 发送请求,之前 DELETE 发送 JSON 数据,后端无法接收到.

目前 4 种请求方式对应使用的数据类型是:

• GET application/x-www-form-urlencoded
• POST [ "application/json;charset=UTF-8" ]
• PUT [ "application/json;charset=UTF-8" ]
• DELETE application/x-www-form-urlencoded

[hantsy]

还有之前看到一个什么 Redis 事务，同类。牛的病，能够扯到猪身上去了。

[hantsy]

我的例子中，https://github.com/hantsy/spring-reactive-jwt-sample/blob/master/src/main/java/com/example/demo/domain/Post.java

也有 DRAFT，PUBLISHED 两个状态，这能跟 Http Status 扯上关系。

这种思维闻所未闻。今天算是开一个眼界了，Fielding 原来这么不受待见，还不如 V 站一个小喷壶，英文都看不懂的情况非要说他说的资源是文件。

[est]

@iugo 我的观点是，所有业务一旦进入流程都 200 是一个很好的设计。404 只能表示这个 API 入口被删了。不能表示资源不见了。 那种把物品 id 放到 URL 路径一部分的做法，RESTful 一时爽，nginx 日志分析火葬场。

[libook]

@iugo 题主问的是 RESTful 应该返回什么状态码，我的态度很明确，返回啥都行，因为根本就不是 REST 的核心概念所关心的。
但是 HTTP 协议关心这个，所以老老实实按照 W3C 的标准文档来定义返回什么状态码就行了。

你举的两个例子可以是你的一种实践方案，如果适合你的业务的话是完全可以用的。

所以。。。真没必要跟我这里强调应该用哪种，因为我压根没有说哪种好哪种不好，都是看实际用起来是否好用。

[bestwaytowait]

赶紧别用 restful 了……省着吵架；

我记得有个 GraphQL，不知道是不是摆脱了这种问题……

[hantsy]

@bestwaytowait GraphQL 可以解决一部分 REST 上的缺陷问题。

从某些角度，我感觉 GraphQL 是弥补了 REST 返回数据颗粒控制上问题。以前我一些做法是尽可能让 REST API 足够细， 返回数据足够细，结果面临的问题是，要么前端一个页面往往要调用多次聚合数据显示 （当然这和国内的前端水平也有很大关系，如果按 React 的 Presenter/Container 模式，页面可以组件切得足够细，逻辑和展示完全可以分离，而我看到的代码很多一个页面对应一个巨无霸组件解决），要么另外在服务器加一个 Gateway 去按需求聚合数据。

如果按 REST 思维去度量 GraphQL，GraphQL 完全违背了 REST 。一句话，GraphQL 不是 REST，而是为 API 开发提供了另外一种选择。

[jones2000]

@hantsy 这个是一个页面版的数据库查询分析器用来给学生学习数据库课程的， 学生通过页面编辑器直接写 sql 查询，创建表 等数据库的相关操作， 允许写错误的 sql 语句，通过执行报错在前端显示出来。如果直接就提示错误， 没有任何错误信息，学生根本就不知道怎么修正他的 sql 语句

[kalista]

我们也是全部返回 200，我这个菜鸟倒是挺好理解，不过也遇到过特殊情况需要使用 40x 就是

[hyperbin]

@yaphets666 别告诉我 2020 年了还没用 HTTPS

[cruii]

@zsdroid
那干脆用你的业务码取代 HTTP Code 吧。反正最后都是看你的业务码。对你来说，HTTP Code 无非就是个摆设。勿回。

[smartqq]

统一返回 200 是国情 没毛病的
很久以前返回 404 等 code 会被运营商重定向。。。

[iugo]

虽然对于这种人造的, 有历史的东西, 争论没有意义. 但我觉得在这个过程中, 我们能对什么是更好的有更多的理解. 我们的讨论都是在表述自己的理解, 不存在说服谁的问题.

以下都是我的想法, 不是客观正确的, 是我认为正确的. 不是要说服谁, 是想表达让大家参考, 也期待大家有相关的分享让我参考. 讨论的目的只是互通有无.

## 关于是否使用 REST

首先, 如果不用 REST, 进入业务后都返回 200 是一种我可以接受的设计. 这点我觉得没有问题. 我的个人经验是, 交互业务重时, REST 捉襟见肘.

## 关于什么是 HTTP Client

但当我作为前端时, 我可能更希望大家去使用 HTTP 状态码而不是不去用. 因为我这个前端不认为 4xx 错误码是给前端代码用的, 而是给用户的. Client 可能表示前端代码, 浏览器, 用户. 前端也是 user agent, 和浏览器一样, client 应该主要代表 user, 而不是 user agent.

## 是否要用 HTTP 状态码

基于与 HTTP Client 的想法, 所以我倾向于 API 使用更多的 HTTP 状态码.

## 关于 REST 最初设计的想法 (暂存草稿)

https://v2ex.com/t/689938?p=1#r_9251862

> The key abstraction of information in REST is a resource.

- HTTP 协议有状态码设计.

> Although those implementations reflect many of the design constraints of REST, having been developed by people familiar with the Web's architectural design and rationale, the real WWW architecture is independent of any single implementation. The modern Web is defined by its standard interfaces and protocols, not how those interfaces and protocols are implemented in a given piece of software.

- REST 存在一些设计约束, 这些设计约束来源于当时的 WWW 实现(比如 libwww, 在现在我已经不知道这是个什么东西了, 应该类似于 HTTP 服务端与浏览器的结合吧).
- WWW 是独立的, 不受制于任何软件设计实现, REST 也是一种利用 WWW 实现业务的设计实现, 不应该被排除, 大家可以考虑考虑.