Спокойный способ удаления всех предметов

Question

Я разрабатываю API для администратора домена для управления пользовательскими кулинарными сеансами ie, в частности

GET users/{userKey}/sessions, чтобы получить список всех сеансов пользователя
DELETE users/{userKey}/sessions/{sessionId} для удаления указанных пользователем данных. c сеанс

Я хочу предложить другому способу администратора удалить (сбросить) все сеансы пользователя. Я рассматриваю 2 варианта, мне интересно, какой из них более успокаивающий

1. DELETE users/{userKey}/sessions - {sessionId} оставлен пустым, чтобы удалить все сеансы
2. POST users/{userKey}/sessions/reset

Answer 1

Я хочу предложить другому способу администратора удалить (сбросить) все сеансы пользователя. Я рассматриваю 2 варианта, интересно, какой из них более успокоительный ...

Возможно, вы хотите использовать POST .

POST служит для многих полезных целей в HTTP, включая общую цель «это действие не стоит стандартизировать». - Fielding, 2008 .

HTTP DELETE не часто является правильным ответом

Относительно небольшое количество ресурсов позволяет метод DELETE - его основной используется для удаленных сред разработки, где у пользователя есть какое-то направление относительно его эффекта. - RF C 7231

Методы HTTP относятся к домену "передача документов по сети", а не к вашему домену.

REST на самом деле не заботится о написании цели-uri - это часть вопроса. HTTP-компоненты общего назначения не предполагают, что в uri есть какая-либо специфицированная c семантика, закодированная в нем. Это просто непрозрачный идентификатор.

Это означает, что вы можете применять любую эвристику разработки URI, которая вам нравится. Это очень похоже на выбор имени для переменной или пространства имен на языке программирования общего назначения; компилятор / интерпретатор обычно не заботится о том, означает ли символ что-либо или нет. Мы выбираем имена, которые облегчают жизнь людям , которые взаимодействуют с кодом.

Так же как и с URI. Возможно, вы захотите использовать орфографию, которая совместима с другими идентификаторами в вашем API, так что это выглядит так, как если бы API был спроектирован «одним умом».

Общий подход начинается с идеи, что Ресурс - это любая информация, которую можно назвать ( Fielding, 2000 ). Поэтому наша задача сначала (а) выяснить имя ресурса, который обрабатывает этот запрос, а затем (б) определить идентификатор, который «соответствует» этому имени. Ресурсы очень похожи на документы , поэтому, если вы можете придумать название документа, в котором вы написали бы это сообщение, вы можете найти способ выяснить имя (например: мы записываем сеансы с истекающим сроком в "журнал безопасности" или в "журнал сеансов". Отлично, теперь выясните соответствующий URI.)

Если I управлял зоопарком: я представляю, что

GET /users/{userKey}/sessions

, вероятно, вернет представление о пользовательских сессиях повара ie. Поскольку это представление будет изменяться при удалении всех пользовательских сессий, я бы хотел опубликовать запрос на удаление в тот же целевой URI

POST /users/{userKey}/sessions

, потому что при таком выполнении создается кэш аннулирование история немного проще.

Answer 2

REST никогда не был предназначен для поддержки массовых транзакций, он предназначен для представления состояния отдельных объектов. Тем не менее, дизайн API очень самоуверенный, и вы должны сбалансировать «чистоту» REST с функциональностью. Если бы я проектировал это, я бы go использовал вариант 1 и использовал бы удаление в конечной точке "сессий", так как вы удаляете все пользовательские сессии, а не только одну или подмножество.

Answer 3

Я бы go с DELETE @ users/sessions

Если вы думаете об этом, сброс - это просто администратор, удаляющий сеанс. Пользователь получает свой новый сеанс, когда / если они возвращаются. Таким образом, маршрут сброса не имеет особого смысла, так как в этом действии вы не переписываете сеансы всем своим пользователям.

Я предпочитаю users/sessions, а не users/{*}/sessions. Более поздний маршрут предполагает, что вы хотите удалить все сеансы родительского ресурса, в данном случае это один пользователь.

Answer 4

Этот ответ может быть основан на мнении, поэтому принимайте его как таковой. Я бы использовал DELETE , если вы удаляете ресурс (так как вы собираетесь удалять сеансы).

Если вы сохраняете сеансы (но изменяете некоторые данные в этих ресурсах, например, скользящий срок действия), тогда я хотел бы рассмотреть возможность использования PATCH , поскольку вы изменяете (сброс и не замена) существующих сессий.