REST - HTTP DELETE - семантика - удалять только потомков - PullRequest
Новая
       14

REST - HTTP DELETE - семантика - удалять только потомков

5 голосов
/ 16 июля 2011

В нашем проекте список всех книг можно получить с помощью REST: 

GET http://server/api/books/

Определенную книгу можно получить следующим образом: 

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

Удаление определенной книгипросто: 

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

Теперь, на мой вопрос: каким должен быть результат следующего вызова: 

DELETE http://server/api/books/

Очевидно, что все книги удалены.Но следует ли также удалить ресурс books / ?То есть после запроса:

  1. должен GET / books / return 200 OK с пустым списком?или
  2. если GET / books / return 404 не найден?

В соответствии со спецификацией, в которой говорится, что конкретный URI впоследствии пропадет, я бы выбрал второй вариант,Однако, на мой взгляд, это делает вещи сложными и нелогичными.Имеет смысл иметь пустой список книг вместо без книг .

Что вы думаете?

Ответы [ 3 ]

2 голосов
/ 16 июля 2011

Если вам от этого легче, предположите, что на сервере есть логика, которая автоматически воссоздает ресурс books после его удаления.: -)

Я бы пошел на 200 ОК и пустой список.Если вам это не нравится, создайте новый ресурс с именем /books/all

и выполните 

DELETE /Books/all
0 голосов
/ 17 июля 2011

Я думаю, что разрешить DELETE /books слишком рискованно. Частью хорошо разработанного API-интерфейса является предотвращение «легких» ошибок со стороны API-клиента. Может легко случиться так, что в клиентском коде что-то идет не так, случайно идентификатор (например, переменная пустой строки) отсутствует и отправляется непреднамеренно DELETE /books.

Я бы заставил клиента выполнить итерацию по DELETE /books/{id} на тот случай, если он захочет удалить все книги.

Может быть, вы можете дать больше информации о вашем сценарии использования: мне интересно, насколько вероятен сценарий использования, который называется DELETE /books в качестве корневого источника (удаление корневых ресурсов довольно радикально). Возможно, вы предлагаете удалить подресурс, например, /user/{id}/shopping-cart/{id}/books. Если это более «временный» ресурс (как в корзине покупок), удаление api для всех книг имело бы больше смысла.

По поводу вашего другого вопроса: Для /books я бы вернул 200 и пустой список. В случаях сбора данных я предпочитаю пустые списки, а не нулевые значения.

0 голосов
/ 16 июля 2011

Однако это усложняет и не логично

Как? Вы запрашиваете удаление ресурса. Этот ресурс удален. В результате этого его больше нет.

Во всяком случае, сбивает с толку его присутствие после его удаления.

...