我没有代码要显示，因为我认为主题不言自明。在这里应该使用什么是正确的HTTP谓词？删除还是修补？
基本上，数据将被标记为isDel=true，delAt=时间戳。
更新(2023年2月26日(：
获取数据将导致404未找到
"这取决于"。
如果您正在编辑表示，例如，将isDel和delAt属性添加到文档并将这些更改发送到服务器，那么您应该使用用于更改表示的方法之一(PATCH、PUT或POST(。
如果要删除资源及其表示形式之间的关联，则可以使用DELETE。如果碰巧服务器将表示修改为DELETE的副作用。。。好吧，这只是隐藏在HTTP门面后面的一个实现细节。
如果您设想在请求中发送有效负载，那么DELETE是正确的，因为DELETE请求的有效负载没有定义的语义——不能保证通用组件将有效负载一直转发到原始服务器。
另请注意：
允许DELETE方法的资源相对较少——它的主要用途是用于远程创作环境，在那里用户可以了解其效果。
请记住，DELETE和其他HTTP方法一样，是通过网络域传输文档时的语义表达，而不是您的问题域。
尽我所愿需要考虑的独立性
那么您也应该考虑实现PUT。
PUT和PATCH都植根于"；远程创作"；；客户端对资源的本地表示进行更改，然后要求服务器对其本地副本进行相同的更改。
两者之间的区别：使用PUT，我们发送资源的整个表示；使用PATCH，我们会发送一个仅描述更改的补丁文档。
如果在服务器上同时实现这两种方法，则客户端可以根据其条件选择适当的方法。例如，如果表示的大小相对于HTTP标头较小，则客户端可能始终选择使用PUT，因为如果消息传输不可靠，HTTP应用程序可以利用方法约束。
另一方面，当表示非常大，而更改很小时，发送补丁可能更有意义。
它们只是服务器端状态，GET或我们现有的任何API都无法检索。
如果DELETE的语义不合适，并且您没有查看属于表示的信息，那么可以使用POST。
POST在HTTP中有许多有用的用途，包括"；这种行为不值得标准化"——Fielding，2008
RFC-2616对DELETE有这样的看法：
DELETE方法请求源服务器删除由请求URI标识的资源。此方法可能会被原始服务器上的人工干预(或其他方式(覆盖。即使从原始服务器返回的状态代码指示操作已成功完成，也无法保证客户端已执行操作。但是，服务器不应该指示成功，除非在给出响应时，它打算删除资源或将其移动到无法访问的位置。
如果isDel的值指示后续GET无法访问该记录，则IMO将视为将资源移动到不可访问的位置，因此DELETE是合适的。
请注意，这样的记录可以通过未来的PUT有效地恢复，只需切换isDel的值，而不必重新创建资源：
PUT /foo/bar # Create the resource
GET /foo/bar # Retrieve it
DELETE /foo/bar # "Delete" it
GET /foo/bar # 404 not found
PUT /foo/bar # Make it available again
GET /foo/bar # Retrieve it