2014年6月，RFC7231废除了RFC2616。如果您正在通过HTTP进行REST，那么RFC7231将准确描述GET、PUT、POST和DELETE的预期行为

除了200和204之外，205（重置内容）可能是有效的响应。

服务器已完成请求，用户代理应重置导致发送请求的文档视图。。。[例如]清除输入的形式。

对于PUT请求：HTTP 200，HTTP 204应暗示“资源更新成功”。如果PUT请求创建了新资源，则返回HTTP 201。

对于DELETE请求：HTTP 200或HTTP 204应表示“已成功删除资源”。

HTTP 202也可以通过任一操作返回，并暗示该指令已被服务器接受，但尚未完全应用。稍后操作可能会失败，因此客户端不应该完全认为它是成功的。

如果客户机接收到一个它无法识别的状态代码，但它以2开头，则应将其视为200 OK。

看跌，看跌如果修改了现有资源，则应发送200（OK）或204（No Content）响应代码，以指示请求成功完成。

删除如果响应包括描述状态的实体，则成功响应应为200（OK）；如果动作尚未实施，则为202（已接受）；如果已实施动作但响应不包括实体，则为204（无内容）。

来源：IETF:RFC-9110方法定义

HTTP 200 OK：成功HTTP的标准响应请求。实际响应将取决于使用的请求方法。HTTP 204无内容：服务器已成功处理请求，但未返回任何内容

来源：HTTP状态代码列表：2xx成功

2014年6月，RFC7231废除了RFC2616。如果您正在通过HTTP进行REST，那么RFC7231将准确描述GET、PUT、POST和DELETE的预期行为

通常，200 OK和201 Created最适合成功的PUT请求。

对于DELETE方法，202接受和204无内容将是最佳选择。

由于这个问题探究了DELETE“应该”返回200而不是204，因此值得考虑的是，有些人建议返回带有链接的实体，因此首选200。

“与其返回204（无内容），API应该是有用的建议去哪里。在这个例子中，我认为provide是“'somewhere.com/container/'（减去'resource'）”-容器客户端刚刚删除了一个资源。也许客户希望删除更多资源，这样将是一个有用的链接。"

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

如果客户机遇到204响应，它可以放弃或转到API的入口点，或返回到上一个资源访问。两种选择都不是特别好。

就我个人而言，我不会说204是错误的（作者也不会；他说“令人讨厌”），因为客户端的良好缓存有很多好处。最好是保持一致。