在宁静的服务中处理孤立数据

Question

假设我有一个具有任务列表的RESTful服务。

GET mycorp/api/v1/tasks 

这些任务中的每一个都可以有一个或多个上下文。

GET mycorp/api/v1/tasks?context=somecontext 

在使用过程中，用户会删除一批任务。

DELETE mycorp/api/v1/tasks?context=somecontext 

让我们假设一旦执行此操作，我们已经是现在孤立的系统，因为上面的DELETE操作的一些背景。让我们假设可以让孤立的上下文来保存用户不得不一遍一遍地输入相同的上下文。

如果用户DID想要显式删除这些上下文，那么在REST上下文中正确的方法是什么？我自然倾向于两种选择。

DELETE mycorp/api/v1/tasks?context=somecontext&&deleteorphancontexts=true 

而且还

DELETE mycorp/api/v1/contexts?isorphaned=true 

我还是新来休息，什么以确保我打造的API是刚性的无意义。

Answer 1

首先，REST并不是一套严格的指导方针，所以对此没有明确的答案，但我认为它会帮助你将不同的URL视为资源（毕竟REST是关于什么的）。

向服务器发送DELETE请求时，指示它删除该位置的资源。在你的例子中，你假定你正在删除一个集合的内容，但你实际上是在指示服务器删除集合本身。因此，如果您在之后立即发出GET请求，则应该会得到204（无内容）响应，而不是200个带有空集合的响应。如果那是合适的，那么你的问题就解决了。

在我看来，对单个上下文/任务使用DELETE请求会更好，因为它与PUT请求相反。通过发出包含删除指定内容的命令的POST请求来修改集合更为正确。

这样，您可以张贴到

MyCorp的/ API/V1 /上下文

并发送指示服务器删除所有孤儿的命令。

我更喜欢这个的原因是，您将上下文路径当作一个集合来处理，其中某些项目可能会成为孤儿。

通常，当你有疑问POST是你的朋友，因为它是HTTP的小丑。