幂等性接口，操作成功或失败，该返回什么？怎么响应？

[yusheng88]

个人的看法如下：
新增、修改、删除的接口应该返回什么？
1 、返回新增、修改、删除记录的主键、如果待新增记录已存在||待删除记录、待修改记录的记录不存在，则返回 null;操作失败，返回异常信息。 [和工作流系统结合方便，便于暂存业务信息]
2 、操作成功[具有幂等性]，不返回任何数据；操作失败，返回异常信息。 [简单省事]
3 、操作成功，不返回任何数据；如果待新增记录已存在||待删除记录、待修改记录的记录不存在，则返回唯一约束字段；操作失败则返回异常信息。 [方便前端提示是否重复]

批量新增、修改、删除接口呢？
1 、操作成功：返回 map，key 为唯一约束字段，value 为记录的主键，操作失败，返回异常信息。
2 、操作成功[具有幂等性]，不返回任何数据；操作失败，返回异常信息。

[yusheng88]

linux 系统的响应方式，就是操作成功，不返回数据，操作失败，返回异常信息。在业务系统里，这种响应方式是否为主流？个人更倾向于返回操作的记录的主键[id]。

[3dwelcome]

幂等函数 = 每次运行结果都一样，相当于 GET 了。楼主说的增改删，DELETE 这种非幂等函数吧。

国外 REST 主流就是返回状态码，成功 200 或者 204，失败就是返回 404，和普通 HTTP 请求一样。

国内主流就是 POST 一把梭。

[baiyi]

在我看来幂等性和响应内容是无关的。

从 HTTP 的设计上来看。它为 methods 设计两种特性，安全性和幂等性，同时安全的一定是幂等的。安全性表示用户可以随意调用该接口，而不用担心对资源的影响，幂等性表示用户无论调用多少次该结构，对其资源的影响是一定的。
GET：安全且幂等
POST：不安全且不幂等
PUT：不安全但幂等
DELETE：不安全但幂等

先撇开安全不谈，幂等性的设计好处是什么呢？这就是我们设计接口时 POST 和 PUT 的区别。当你将接口设置为 PUT 时，就表示告诉了调用者，这个接口是可以重试的。
用最常见的新增场景来表示，POST 和 PUT 都可以用来添加资源，但 POST 不能重试，每一次请求都有可能添加一个新资源； PUT 可以重试，它只会在服务器中增加一个用户所描述的资源，无论用户重复调用多少次。

给一个典型的例子，为什么 Github v3 API 的 Star 操作是 PUT 而不是 POST，应该就是有幂等性的考虑。
https://docs.github.com/en/rest/reference/activity#star-a-repository-for-the-authenticated-user

[yusheng88]

额，不应该关注幂等性，新增、修改、删除接口返回什么数据比较好？

[baiyi]

@yusheng88 #4 接口的响应数据是与业务紧密关联的，需要服务于调用者。
比如 DELETE 操作，一般情况下是可以响应 204 status，同时响应内容为空。可如果你的业务需要在删除后响应一个关联的资源内容，那么就应该响应 200 status，同时响应关联内容。