Код ответа REST для ресурсов, которые не могут быть обновлены
У меня есть ресурс, который не может быть обновлен (события). Поэтому я разрешаю только операции Post & Get. (Я не выбрал PUT, потому что идентификатор события генерируется в конце сервера и возвращается как часть ответа).
У меня уже есть комбинация из трех полей на входе, которые можно использовать для идентификации уникального ресурса.
Учитывая это, если кто-то отправляет один и тот же запрос дважды, это то, что я ожидаю вернуть
- Случай 1: Если уникальные поля уже существуют в БД и полный запрос точно такой же, как и предыдущий, мы просто игнорируем этот запрос (так как ресурс уже существует).
- случай 2: если уникальные поля уже существуют в БД, НО другая часть запроса отличается, то отправьте ответ об ошибке, сказав, что он не поддерживается.
Какой должен быть правильный код ответа для возврата в случае 1 и 2.
Спасибо хариш
2 ответа
Если вызов идемпотентен, что означает случай 1, я ожидаю, что он вернет 200 OK, потому что на самом деле он не потерпел неудачу, это то же самое, что обновление с теми же значениями при выполнении PUT.
Если вызов не идемпотентен, что означает случай 2, я бы ожидал конфликт 409, даже если пользователь фактически не должен повторять вызов. Это потому, что, как вы сказали, пользователю действительно разрешено отправлять запрос с теми же идентификаторами, при условии, что все остальные параметры также одинаковы.
Кроме того, но это только мое внутреннее чувство: если пользователь попробовал разные параметры, чтобы увидеть код ответа другого типа, он мог бы определить текущее состояние ресурса, даже если, возможно, ему не разрешили его прочитать. Поэтому, в зависимости от области применения вашего приложения, вы можете захотеть вернуть тот же ответ.
РЕДАКТИРОВАТЬ:
Поскольку ни 409, ни 400 не подходят для вашего случая, возможно, 422 Unprocessable Entity
http://www.restpatterns.org/HTTP_Status_Codes/422_-_Unprocessable_Entity
Возможно, 409 Conflict - это то, что вы ищете.
Если вы хотите сообщить клиенту, что сбой является "окончательным", и редактирование запроса не изменит это, другой вариант - 400 Bad Request.
Лично я использую только 400, когда синтаксис запроса недопустим - что здесь не так.