我没有代码要显示,因为我认为主题不言自明。在这里应该使用什么是正确的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