5

在我们的项目中,可以通过 REST 检索所有书籍的列表:

GET http://server/api/books/

可以按以下方式检索特定书籍:

GET http://server/api/books/:id/

删除特定书籍很容易:

DELETE http://server/api/books/:id/

现在,对于我的问题:以下调用的结果应该是什么:

DELETE http://server/api/books/

显然,所有的书都被删除了。但是资源书/也应该被删除吗?也就是说,在请求之后:

  1. GET /books/ 应该返回 200 OK 和一个空列表吗?或者
  2. GET /books/ 是否应该返回 404 未找到?

根据规范,具体的 URI 将在之后消失,我会选择第二个选项。然而,在我看来,这使事情变得复杂和不合逻辑。有一个空的书单没有书更有意义。

你怎么看?

4

3 回答 3

2

如果它让您感觉更好,请假设服务器具有在删除图书资源后自动重新创建图书资源的逻辑。:-)

我会选择 200 OK 和一个空列表。如果您真的不喜欢那样,请创建一个名为的新资源 /books/all

DELETE /Books/all
于 2011-07-16T16:28:57.193 回答
0

然而,这使事情变得复杂和不合逻辑

如何?您正在请求删除资源。该资源被删除。结果是它不再存在了。

如果有的话,在您删除它之后它仍然存在会令人困惑。

于 2011-07-16T15:04:13.423 回答
0

我认为允许DELETE /books太冒险了。设计良好的 api 的一部分是避免来自 api 客户端的“简单”错误。很容易发生在客户端代码中出现问题,意外地丢失了 id(例如空字符串变量)并且DELETE /books发送了意外。

我要做的是强制客户进行迭代DELETE /books/{id},以防他想删除所有书籍。

也许您可以为您的用例提供更多输入:我想知道用例被DELETE /books称为根源的可能性有多大(删除根资源是非常激进的)。也许您正在提供删除子资源,例如/user/{id}/shopping-cart/{id}/books. 如果它是一个更“临时”的资源(如购物车),删除所有书籍的 api 会更有意义。

关于您的另一个问题:因为/books我会返回200并清空列表。在收集情况下,我更喜欢空列表而不是“空”值。

于 2011-07-16T21:07:57.393 回答