ChatGPT解决这个技术问题 Extra ChatGPT

更新和删除的 HTTP 状态码?

我应该为 UPDATE (PUT) 和 DELETE 设置什么状态代码(例如产品成功更新)?


E
Evert

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

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

HTTP 202 也可以由任一操作返回,这意味着该指令已被服务器接受,但尚未完全应用。稍后操作可能会失败,因此客户端不应完全假设它是成功的。

接收到它无法识别但以 2 开头的状态代码的客户端应将其视为 200 OK。

PUT 如果修改了现有资源,则应发送 200(OK)或 204(No Content)响应代码以指示请求成功完成。

DELETE 如果响应包含描述状态的实体,则成功的响应应该是 200(OK),如果尚未执行该操作,则应为 202(已接受),如果已执行该操作但响应未执行,则应为 204(无内容)包括一个实体。

来源:W3.org: HTTP/1.1 Method Definitions

HTTP 200 OK:成功的 HTTP 请求的标准响应。实际响应将取决于使用的请求方法。 HTTP 204 No Content:服务器成功处理了请求,但没有返回任何内容

来源:List of HTTP status codes: 2xx Success


很有用的帖子!但是我想知道 HTTP 状态代码应该是什么,客户端发送的请求是有效的(DELETE mySite/entity/123)并且要删除的实体不存在。
@Martin:在这种情况下,服务应该返回 HTTP 404。严格来说,对不存在的资源的 DELETE 或 GET 请求不是“有效”请求 - 即。客户端不应重新尝试该请求,因为它永远不会成功... HTTP 协议定义了 2 类问题 - 具有 4xx 状态代码的问题,客户端必须在重试之前修改请求,以及具有 5xx 状态的问题代码,这表明服务遇到问题并且客户端应该/可以重试相同的确切请求而不更改它。
@JeffMartin 从用户的角度来看可能是这样,但就服务器而言,如果资源不存在,服务器应该返回 404。
@Randolpho,幂等性就是要获得相同的结果,无论您调用一次还是多次。客户要求您确保删除该资源。返回 404 有什么好处?为什么它需要知道任何一种方式?现在客户端逻辑必须处理两个单独的响应代码而不是一个。
@Gili:也许 the wiki 会更好地解释:方法 PUT 和 DELETE 被定义为幂等...注意幂等是指请求完成后系统的状态,所以当服务器采取的行动时(例如删除一条记录)或它返回的响应码在后续请求中可能不同,系统状态每次都相同。
H
Haralan Dobrev

简短回答:对于 PUT 和 DELETE,您应该发送 200(OK)或 204(No Content)。

长答案:这是一个完整的决策图(点击放大)。

https://raw.githubusercontent.com/for-GET/http-decision-diagram/master/httpdd.png

来源:https://github.com/for-GET/http-decision-diagram


图表是惊人的。有更高分辨率的版本可以打印吗?
在现有资源的 POST 上下文中,另一个 SO 讨论 (stackoverflow.com/questions/3825990/…) 建议发送 409 Conflict 或 302 Found 而不是附加内容。
我很好奇删除发生后的 204 和 200 响应是否应该反转,如果它们是正确的,为什么?删除? -> 响应包括一个实体? -> 是 -> 204 无内容;否 -> 200 确定
@docksteaderluke 很棒的东西,但为什么那里没有 POST 代码?
我认为应该交换“已删除?/响应包含实体?/是和否”标签?任何响应实体都不应导致 204。
C
Community

这里有一些提示:

删除

200(如果您想在响应中发送一些额外的数据)或 204(推荐)。 202 删除的操作尚未提交。如果没有什么要删除的,就用204或者404(DELETE操作是幂等的,删除一个已经删除的项是操作成功,所以可以返回204,但是确实幂等不一定表示同样的响应) 其他错误:400 Bad请求(格式错误的语法或错误的查询很奇怪,但可能)。 401 Unauthorized Authentication failure 403 Forbidden:授权失败或无效的应用程序 ID。 405 不允许。当然。 409 资源冲突在复杂系统中是可能的。和 501、502 以防出错。

如果您使用与上述 DELETE 相同的原因更新集合 200/204 的元素。 202 如果操作尚未提交。引用的元素不存在:PUT 可以是 201(如果您创建了元素,因为那是您的行为) 404 如果您不想通过 PUT 创建元素。 400 错误请求(格式错误的语法或错误查询比 DELETE 更常见)。 401 Unauthorized 403 Forbidden:身份验证失败或无效的应用程序 ID。 405 不允许。当然。 409 资源冲突在复杂系统中可能发生,例如在 DELETE 中。 422 Unprocessable entity 它有助于区分“错误请求”(例如格式错误的 XML/JSON)和无效字段值以及 501、502 以防出错。


这个答案几乎完全由两个大引号组成,但没有归属。你从哪里引用?
如果状态未有效更改,204 是否是返回 PUT 请求的正确状态?例如,您要求停用用户,但该用户已经处于非活动状态。
PUT 请求是幂等的,所以可以返回 204,因为对象在系统中发生了变化。 PUT 不是 PATCH,因此您不确定要更改哪个字段。如果您的设计需要知道对象是否与请求中的对象完全相同,您可以发回 501 - 502 但是......我不太喜欢它.. 我更喜欢 204,或者,如果你想停用用户,无需更改更多字段,也许您可以使用 PATCH。
我会添加 HTTP 422 Unprocessable Entity。它有助于区分“错误请求”(例如格式错误的 XML/JSON)和无效字段值。
@AlfonsoTienda 在缺少父资源时在 DELETE 上返回什么? (例如,如果我们收到 DELETE {{restful-api-base}}/departments/1/colleagues/2 我们应该说 404 没有这样的部门 1 还是说 204 已删除,即使部门 1 不存在并且我们正在尝试删除同事其中 2 个)
I
Ignacio Vazquez-Abrams

RFC 2616 描述了 which status codes to use

不,它并不总是 200。


P
Prince Dholakiya

这是一些状态代码,您应该根据自己的知识了解。

1XX 信息回复

100 继续 101 交换协议 102 处理 103 早期提示

2XX 成功

200 OK 201 Created 202 Accepted 203 非权威信息 204 无内容 205 重置内容 206 部分内容 207 多状态 208 已报告 226 IM 已使用

3XX 重定向

300 多项选择 301 永久移动 302 找到 303 查看其他 304 未修改 305 使用代理 306 切换代理 307 临时重定向 308 永久重定向

4XX 客户端错误

400 错误请求 401 未经授权 402 需要付款 403 禁止 404 未找到 405 方法不允许 406 不可接受 407 需要代理身份验证 408 请求超时 409 冲突 410 消失 411 需要长度 412 前提条件失败 413 有效负载太大 414 URI 太长 415 不支持的媒体类型 416范围不满足 417 期望失败 418 我是一个茶壶 420 方法失败 421 错误的请求 422 无法处理的实体 423 锁定 424 依赖失败 426 需要升级 428 需要前置条件 429 请求太多 431 请求标头字段太大 451 由于法律原因不可用

5XX 服务器错误

500 内部服务器错误 501 未实施 502 网关错误 503 服务不可用 504 网关超时 505 Http 版本不支持 506 变量也协商 507 存储空间不足 508 检测到环路 510 未扩展 511 需要网络身份验证


p
pje

除了 200 和 204 之外,205 (Reset Content) 可能是有效响应。

服务器已经完成了请求,并且用户代理应该重置导致请求被发送的文档视图... [例如] 清除给出输入的表单。


P
Paulo Merson

由于问题深入探讨了 DELETE “应该”是否返回 200 与 204,因此值得考虑的是,有些人建议返回带有链接的实体,因此首选是 200。

“而不是返回 204(无内容),API 应该有帮助并建议去的地方。在这个例子中,我认为提供的一个明显链接是“'somewhere.com/container/'(减去'资源')“-客户刚刚从中删除资源的容器。也许客户希望删除更多资源,所以这将是一个有用的链接。

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

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

就我个人而言,我不会说 204 是错误的(作者也没有;他说“烦人”),因为客户端的良好缓存有很多好处。最好的方式是保持一致。


C
Community

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


R
Rohit Parte
{
    "VALIDATON_ERROR": {
        "code": 512,
        "message": "Validation error"
    },
    "CONTINUE": {
        "code": 100,
        "message": "Continue"
    },
    "SWITCHING_PROTOCOLS": {
        "code": 101,
        "message": "Switching Protocols"
    },
    "PROCESSING": {
        "code": 102,
        "message": "Processing"
    },
    "OK": {
        "code": 200,
        "message": "OK"
    },
    "CREATED": {
        "code": 201,
        "message": "Created"
    },
    "ACCEPTED": {
        "code": 202,
        "message": "Accepted"
    },
    "NON_AUTHORITATIVE_INFORMATION": {
        "code": 203,
        "message": "Non Authoritative Information"
    },
    "NO_CONTENT": {
        "code": 204,
        "message": "No Content"
    },
    "RESET_CONTENT": {
        "code": 205,
        "message": "Reset Content"
    },
    "PARTIAL_CONTENT": {
        "code": 206,
        "message": "Partial Content"
    },
    "MULTI_STATUS": {
        "code": 207,
        "message": "Multi-Status"
    },
    "MULTIPLE_CHOICES": {
        "code": 300,
        "message": "Multiple Choices"
    },
    "MOVED_PERMANENTLY": {
        "code": 301,
        "message": "Moved Permanently"
    },
    "MOVED_TEMPORARILY": {
        "code": 302,
        "message": "Moved Temporarily"
    },
    "SEE_OTHER": {
        "code": 303,
        "message": "See Other"
    },
    "NOT_MODIFIED": {
        "code": 304,
        "message": "Not Modified"
    },
    "USE_PROXY": {
        "code": 305,
        "message": "Use Proxy"
    },
    "TEMPORARY_REDIRECT": {
        "code": 307,
        "message": "Temporary Redirect"
    },
    "PERMANENT_REDIRECT": {
        "code": 308,
        "message": "Permanent Redirect"
    },
    "BAD_REQUEST": {
        "code": 400,
        "message": "Bad Request"
    },
    "UNAUTHORIZED": {
        "code": 401,
        "message": "Unauthorized"
    },
    "PAYMENT_REQUIRED": {
        "code": 402,
        "message": "Payment Required"
    },
    "FORBIDDEN": {
        "code": 403,
        "message": "Forbidden"
    },
    "NOT_FOUND": {
        "code": 404,
        "message": "Not Found"
    },
    "METHOD_NOT_ALLOWED": {
        "code": 405,
        "message": "Method Not Allowed"
    },
    "NOT_ACCEPTABLE": {
        "code": 406,
        "message": "Not Acceptable"
    },
    "PROXY_AUTHENTICATION_REQUIRED": {
        "code": 407,
        "message": "Proxy Authentication Required"
    },
    "REQUEST_TIMEOUT": {
        "code": 408,
        "message": "Request Timeout"
    },
    "CONFLICT": {
        "code": 409,
        "message": "Conflict"
    },
    "GONE": {
        "code": 410,
        "message": "Gone"
    },
    "LENGTH_REQUIRED": {
        "code": 411,
        "message": "Length Required"
    },
    "PRECONDITION_FAILED": {
        "code": 412,
        "message": "Precondition Failed"
    },
    "REQUEST_TOO_LONG": {
        "code": 413,
        "message": "Request Entity Too Large"
    },
    "REQUEST_URI_TOO_LONG": {
        "code": 414,
        "message": "Request-URI Too Long"
    },
    "UNSUPPORTED_MEDIA_TYPE": {
        "code": 415,
        "message": "Unsupported Media Type"
    },
    "REQUESTED_RANGE_NOT_SATISFIABLE": {
        "code": 416,
        "message": "Requested Range Not Satisfiable"
    },
    "EXPECTATION_FAILED": {
        "code": 417,
        "message": "Expectation Failed"
    },
    "IM_A_TEAPOT": {
        "code": 418,
        "message": "I'm a teapot"
    },
    "INSUFFICIENT_SPACE_ON_RESOURCE": {
        "code": 419,
        "message": "Insufficient Space on Resource"
    },
    "METHOD_FAILURE": {
        "code": 420,
        "message": "Method Failure"
    },
    "UNPROCESSABLE_ENTITY": {
        "code": 422,
        "message": "Unprocessable Entity"
    },
    "LOCKED": {
        "code": 423,
        "message": "Locked"
    },
    "FAILED_DEPENDENCY": {
        "code": 424,
        "message": "Failed Dependency"
    },
    "PRECONDITION_REQUIRED": {
        "code": 428,
        "message": "Precondition Required"
    },
    "TOO_MANY_REQUESTS": {
        "code": 429,
        "message": "Too Many Requests"
    },
    "REQUEST_HEADER_FIELDS_TOO_LARGE": {
        "code": 431,
        "message": "Request Header Fields Too"
    },
    "UNAVAILABLE_FOR_LEGAL_REASONS": {
        "code": 451,
        "message": "Unavailable For Legal Reasons"
    },
    "INTERNAL_SERVER_ERROR": {
        "code": 500,
        "message": "Internal Server Error"
    },
    "NOT_IMPLEMENTED": {
        "code": 501,
        "message": "Not Implemented"
    },
    "BAD_GATEWAY": {
        "code": 502,
        "message": "Bad Gateway"
    },
    "SERVICE_UNAVAILABLE": {
        "code": 503,
        "message": "Service Unavailable"
    },
    "GATEWAY_TIMEOUT": {
        "code": 504,
        "message": "Gateway Timeout"
    },
    "HTTP_VERSION_NOT_SUPPORTED": {
        "code": 505,
        "message": "HTTP Version Not Supported"
    },
    "INSUFFICIENT_STORAGE": {
        "code": 507,
        "message": "Insufficient Storage"
    },
    "NETWORK_AUTHENTICATION_REQUIRED": {
        "code": 511,
        "message": "Network Authentication Required"
    }
}

512 似乎有点偏离,它没有标准化,我假设验证错误在 4xx 范围内(如 422)。你从哪里得到这份清单的?
P
Pratham

通常,200 OK201 Created 最适合成功的 PUT 请求。

对于 DELETE 方法,202 Accepted204 No Content 将是最佳选择。