ОТДЫХ: УДАЛИТЬ и условия бизнес-логики - PullRequest
Новая
       10

ОТДЫХ: УДАЛИТЬ и условия бизнес-логики

2 голосов
/ 30 декабря 2011

Какова де-факто / общепринятая практика при применении бизнес-логики в REST API и какие коды состояния HTTP используются?

Например, допустим, у меня есть сущность Player и сущность Team. Команда может иметь любое количество игроков.

Скажем, моя бизнес-логика (в настоящее время) не позволяет удалять Команду до тех пор, пока все Игроки не будут явно удалены из Команды.

Если вы выполните

DELETE http://api.foo.com/teams/15

и с ним все еще связаны игроки. Вы бы вернули HTTP 409 (конфликт) или HTTP 412 (предусловие не выполнено)? 412 кажется более логичным, потому что я предпочитаю использовать 409 для указания оптимистических условий блокировки.

Или, возможно, следует ли вообще применять это условие бизнес-логики в REST API? То есть если кто-то казнит

DELETE http://api.foo.com/teams/15

не должно ли это просто удалить всех игроков, а затем автоматически удалить команду? Является ли более общепринятым разрешать выполнение DELETE, поскольку REST API может восприниматься как немного «более низкий уровень» или более «сырой», чем интерфейсы пользовательского интерфейса?

Наконец, как насчет параметра запроса в URI ресурса:

DELETE http://api.foo.com/teams/15?force=true

, что означает: «Да, я знаю, что это не будет позволено игрокам, все еще находящимся в команде, но все равно сделайте это».

Идея заключается в том, что удаление Team может быть тяжеловесной операцией со значительными последствиями, и вы хотите делать это только в том случае, если конечный пользователь действительно уверен в этом.

Другими словами, сколько вы держите в руках (используя коды ошибок «вы уверены?») Или вы просто выполняете это без какой-либо проверки? Я не совсем уверен, должно ли это применяться только в пользовательском интерфейсе или в REST API или в обоих. Как большинство людей решают это сегодня?

Ответы [ 3 ]

4 голосов
/ 30 декабря 2011

Клиент пытался сделать что-то, что по деловым причинам не было действительным запросом. Поэтому я бы использовал 400. Используйте тело ReasonPhrase / entity, если вы хотите сообщить дополнительную информацию.

2 голосов
/ 30 декабря 2011

412 было бы неверно в этом случае, так как это основано на оценке полей заголовка запроса (см. этот вопрос о том, когда использовать HTTP 412). Правильный код состояния здесь будет 403 Запрещено - т.е. запрос понятен, но отказывается сделать это, и авторизация не поможет. Вы можете предоставить более подробную информацию клиенту в теле ответа.

Что касается того, должна ли бизнес-логика быть реализована, это полностью зависит от вас. Вы даже можете реализовать такую ​​проверку на основе ACL - например, некоторые пользователи могут УДАЛИТЬ команду только после удаления всех игроков, а администраторы могут УДАЛИТЬ команды независимо от этого. Пользователь без прав администратора, выполняющий запрос DELETE для команды с игроками, теперь должен вернуть 401 Unauthorized (то есть действие для этих учетных данных было отклонено). Администратор получит 200.

РЕДАКТИРОВАТЬ : Больше информации, как всегда, в RFC 2616 .

0 голосов
/ 30 декабря 2011

Я работал в тех случаях, когда служба REST размещалась на лотосных заметках. Если нам нужно удалить какую-либо запись из лотосных заметок, мы обязались установить истинный параметр 'Подтвердить / Принудить', просто чтобы убедиться, что invoker (UI / REST Client)в курсе удаления.Если ваш сервис является сервисом REST, я думаю, что недостаточно иметь уровень UI, нам нужно иметь такое же ограничение и в REST URL.

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

...