Это сложно.
Я думаю, что мы должны;
Вернуть ошибки 4xx только в том случае, если у клиента есть возможность внести изменения в запрос, заголовки или тело, что приведет к успешному выполнению запроса с тем же намерением.
Вернуть коды диапазона ошибок, если ожидаемая мутация не произошла, т.е. УДАЛЕНИЕ не произошло или PUT ничего не изменило. Однако POST более интересен, потому что спецификация говорит, что его следует использовать для создания ресурсов в новом месте или просто для обработки полезной нагрузки.
Если использовать пример из ответа Виша, если в запросе предполагается добавить сотрудника Прия в отдел маркетинга, но Прия не была найдена или ее учетная запись заархивирована, то это ошибка приложения.
Запрос работал нормально, он попал в правила вашего приложения, клиент все сделал правильно, ETag-файлы совпали и т. Д. И т. Д.
Поскольку мы используем HTTP, мы должны отвечать на основании влияния запроса на состояние ресурса. И это зависит от вашего дизайна API.
Возможно, вы разработали это.
PUT { updated members list } /marketing/members
Возвращение кода успеха будет означать, что «замена» ресурса сработала; GET на ресурсе будет отражать ваши изменения, но не будет.
Так что теперь вам нужно выбрать подходящий отрицательный код HTTP, и это сложная часть, поскольку коды строго предназначены для протокола HTTP, а не для вашего приложения.
Когда я читаю официальные коды HTTP, эти два выглядят подходящими.
Код состояния 409 (Конфликт) указывает, что запрос не может быть выполнен из-за конфликта с текущим состоянием целевого ресурса. Этот код используется в ситуациях, когда пользователь может разрешить конфликт и повторно отправить запрос. Сервер ДОЛЖЕН генерировать полезную нагрузку, которая включает в себя достаточно информации, чтобы пользователь мог распознать источник конфликта.
И
Код состояния 500 (Внутренняя ошибка сервера) указывает, что сервер обнаружил непредвиденное состояние, которое не позволило ему выполнить запрос.
Хотя мы традиционно считали, что 500 - это необработанное исключение: - /
Я не считаю неразумным придумывать собственный код состояния, если он последовательно применяется и разрабатывается.
С этим дизайном легче иметь дело.
PUT { membership add command } /accounts/groups/memberships/instructions/1739119
Затем вы можете создать свой API-интерфейс, чтобы всегда успешно создавать инструкцию, он возвращает 201 Created и Location header, и любые проблемы с инструкцией сохраняются в этом новом ресурсе.
POST больше похож на последний PUT в новом месте. POST позволяет обрабатывать сообщения любого типа на сервере, что открывает проекты, которые говорят что-то вроде «Действие успешно завершилось неудачей».
Возможно, вы уже написали API для этого, веб-сайт. Вы отправили платежную форму, и она была успешно отклонена из-за неправильного номера кредитной карты.
При наличии POST вы возвращаете 200 или 201 вместе с сообщением об отказе, зависит от того, был ли создан новый ресурс и доступен ли GET в другом месте или нет.
С учетом всего вышесказанного, я был бы склонен разрабатывать API, которым требуется меньше PUT, возможно, просто обновлять поля данных, а действия и вещи, которые вызывают правила и обработку или просто имеют более высокий шанс ожидаемых сбоев, могут быть разработаны для ПОСТА форма инструкции.