REST: DELETE и условия бизнес-логики

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

EDIT: Дополнительная информация, как всегда, в RFC 2616.

Answer 3

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

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