想要实现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
阿里云 delete rest
“* DELETE（DELETE）：从服务器删除资源。
* DELETE /zoos/ID：删除某个动物园
* DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物
七、状态码（Status Codes）
服务器向用户返回的状态码和提示信息，常见的有以下一些（方括号中是该状态码对应的HTTP动词）。
* 204 NO CONTENT – [DELETE]：用户删除数据成功。”
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
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
HTTP Methods [ RESTful APIs Verbs ] – REST API Tutorial
【总结】
综合官网和其他文档后的解释：
对于DELETE请求，服务器端应该返回的值：
202=Accepted：表示接受了此删除请求
但是暂时还没执行
或者目前执行删除动作，但是还没有完成
之后（服务器端）会完成删除动作
204=No Content：已经执行了删除动作，内容被删除了，没有内容了
response的body中是空的
注意：如果要实现HATEOAS的REST的接口，则尽量避免DELETE返回204
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>