最新消息:20181230 VPS服务器已从Linode换到腾讯云香港,主题仍用朋友推荐的大前端D8

【已解决】Flask的REST接口的最佳实践中DELETE应该返回什么

Flask crifan 463浏览 0评论

想要实现Flask的Flask-Restful中的REST接口,新增一个DELETE接口,然后涉及到应该返回什么值。

需要去研究看看,参考其他BAT等大厂,甚至国外的REST的接口设计中,看看REST中DELETE的最佳实践都应该返回什么。

国外 stripe api delete

Stripe API Reference – Delete a draft invoice

<code>DELETE /v1/invoices/:id
curl https://api.stripe.com/v1/invoices/in_1Cc9wc2eZvKYlo2ClBzJbDQz \
  -u sk_test_4eC39HqLyjWDarjtT1zdp7dc: \
  -X DELETE
{
  "id": "in_1Cc9wc2eZvKYlo2ClBzJbDQz",
  "object": "invoice",
  "deleted": true
}
</code>

阿里云 REST delete

阿里云 delete rest api

Restful API_产品介绍_阿里云Elasticsearch-阿里云

Delete API | Elasticsearch Reference [6.6] | Elastic

<code>DELETE /twitter/_doc/1
COPY AS CURLVIEW IN CONSOLE 
The result of the above delete operation is:
{
    "_shards" : {
        "total" : 2,
        "failed" : 0,
        "successful" : 2
    },
    "_index" : "twitter",
    "_type" : "_doc",
    "_id" : "1",
    "_version" : 2,
    "_primary_term": 1,
    "_seq_no": 5,
    "result": "deleted"
}
</code>

Delete By Query API | Elasticsearch Reference [6.6] | Elastic

REST API 的最佳入门教程-云栖社区-阿里云

阿里云 delete rest

RESTful API 设计指南 – 阮一峰的网络日志

“* DELETE(DELETE):从服务器删除资源。

* DELETE /zoos/ID:删除某个动物园

* DELETE /zoos/ID/animals/ID:删除某个指定动物园的指定动物

七、状态码(Status Codes)

服务器向用户返回的状态码和提示信息,常见的有以下一些(方括号中是该状态码对应的HTTP动词)。

* 204 NO CONTENT – [DELETE]:用户删除数据成功。”

理解RESTful架构 – 阮一峰的网络日志

https://api.github.com/?spm=a2c4e.11153940.blogcont588375.9.1bca3eedR09uSx

Jersey REST 服务中 DELETE 请求无法接收 entity body 作为参数-云栖社区-阿里云

rest – Is an entity body allowed for an HTTP DELETE request? – Stack Overflow

“* a message-body is explicitly forbidden in 1xx (informational), 204 (no content), and 304 (not modified) responses (section 4.3)”

如果服务器后台返回了204,那么BODY就应该是空的

rest what should delete return

http – What REST PUT/POST/DELETE calls should return by a convention? – Stack Overflow

RFC 7231 – Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

“4.3.5. DELETE

 The DELETE method requests that the origin server remove the

   association between the target resource and its current

   functionality.  In effect, this method is similar to the rm command

   in UNIX: it expresses a deletion operation on the URI mapping of the

   origin server rather than an expectation that the previously

   associated information be deleted.

   If the target resource has one or more current representations, they

   might or might not be destroyed by the origin server, and the

   associated storage might or might not be reclaimed, depending

   entirely on the nature of the resource and its implementation by the

   origin server (which are beyond the scope of this specification).

   Likewise, other implementation aspects of a resource might need to be

   deactivated or archived as a result of a DELETE, such as database or

   gateway connections.  In general, it is assumed that the origin

   server will only allow DELETE on resources for which it has a

   prescribed mechanism for accomplishing the deletion.

   Relatively few resources allow the DELETE method — its primary use

   is for remote authoring environments, where the user has some

   direction regarding its effect.  For example, a resource that was

   previously created using a PUT request, or identified via the

   Location header field after a 201 (Created) response to a POST

   request, might allow a corresponding DELETE request to undo those

   actions.  Similarly, custom user agent implementations that implement an authoring function, such as revision control clients using HTTP

   for remote operations, might use DELETE based on an assumption that

   the server’s URI space has been crafted to correspond to a version

   repository.

   If a DELETE method is successfully applied, the origin server SHOULD

   send a 202 (Accepted) status code if the action will likely succeed

   but has not yet been enacted, a 204 (No Content) status code if the

   action has been enacted and no further information is to be supplied,

   or a 200 (OK) status code if the action has been enacted and the

   response message includes a representation describing the status.

   A payload within a DELETE request message has no defined semantics;

   sending a payload body on a DELETE request might cause some existing

   implementations to reject the request.

   Responses to the DELETE method are not cacheable.  If a DELETE

   request passes through a cache that has one or more stored responses

   for the effective request URI, those stored responses will be

   invalidated (see Section 4.4 of [RFC7234]).”

rest – RESTful API: Delete Entity – What should I return as result? – Stack Overflow

200 OK – HTTP | MDN

204 No Content – HTTP | MDN

rest – RESTful – What should a DELETE response body contain – Stack Overflow

Best Practices for Designing a Pragmatic RESTful API | Vinay Sahni

“* 204 No Content – Response to a successful request that won’t be returning a body (like a DELETE request)”

HTTP status code for update and delete? – Stack Overflow

rest – RESTful – What should a DELETE response body contain – Stack Overflow

rest – RESTful API. Should I be returning the object that was created / updated? – Software Engineering Stack Exchange

HTTP Methods [ RESTful APIs Verbs ] – REST API Tutorial

【总结】

综合官网和其他文档后的解释:

对于DELETE请求,服务器端应该返回的值:

  • 202=Accepted:表示接受了此删除请求

    • 但是暂时还没执行

    • 或者目前执行删除动作,但是还没有完成

      • 之后(服务器端)会完成删除动作

  • 204=No Content:已经执行了删除动作,内容被删除了,没有内容了

  • 200=OK:内容已删除,同时返回BODY信息,包含具体的删除的详情

    • response的body中包含额外关于删除的相关信息

      • 比如之前帖子中提到的,删除了具体哪个内容,已删除的状态,甚至删除了符合对应条件的多个内容等等

目前自己所理解的,最佳实践,是:

第三种的:200

且加上之前的返回内容的格式的最佳实践,即code,message,data,则

status code=200

body中json是:

<code>{
  "code": 200,
  "message": "Question deleted for id 5c1777e1cc6df4563adf4a50"
  data: {
    "deletedCount": 1
  }
}
</code>

甚至更加细节的做法:

当检测到想要删除一个已经删除的内容,则返回:

<code>{
  "code": 200,
  "message": "Question already deleted for id 5c1777e1cc6df4563adf4a50"
  data: {
    "deletedCount": 0
  }
}
</code>

转载请注明:在路上 » 【已解决】Flask的REST接口的最佳实践中DELETE应该返回什么

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
61 queries in 0.086 seconds, using 9.99MB memory