REST - HTTP DELETE - semantics - only delete descendants

In our project, a list of all books can be retrieved through REST:

GET http://server/api/books/

A specific book can be retrieved as following:

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

Deleting a specific book is easy:

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

Now, to my question: what should be the result of the following call:

DELETE http://server/api/books/

Obviously, all books are deleted. But should the resource books/ also be deleted? That is, after the request:

1. should GET /books/ return 200 OK with an empty list? or
2. should GET /books/ return 404 not found?

According to the specs, which says that the concrete URI will be gone afterwards, I'd go for the second option. Howev开发者_高级运维er, this makes things complicated and unlogic, in my opinion. It makes more sense to have an empty list of books, instead of no books.

What do you think?

---

If it makes you feel better, assume that the server has logic that recreates the books resource automatically after it has been deleted. :-)

I'd go for 200 OK and an empty list. If you really don't like that then create a new resource called /books/all

and do

DELETE /Books/all

---

However, this makes things complicated and unlogic

How? You are requesting that a resource be deleted. That resource is deleted. The result is that it isn't there any more.

If anything, it's confusing to have it still be present after you deleted it.

---

I think allowing DELETE /books is too risky. Part of a well designed api is to avoid "easy" mistakes from api-client side. It could easily happen that in client code something is going wrong, accidently the id (e.g. empty-string variable) is missing and unintended DELETE /books is sent.

What I would do is to force the client to iterate through DELETE /books/{id} in case he wants to delete all books.

Maybe you can give more input on your use-case: I wonder how likely the use-case is that DELETE /books as root source called (it is quite radical to delete root resources). Maybe you are offering deleting a sub-resource, e.g. /user/{id}/shopping-cart/{id}/books. If it is a more "transient" resource (like shopping-cart is) deleting api for all books would make more sense.

Regarding your other question: For /books I would return 200 and empty list. In collection cases I much prefer empty-lists over 'null' values.