Должна ли RESTful-операция 'PUT' вернуть что-то
Проблема связана с тем, как классы весенней нагрузки и прокси. Это не сработает, пока вы не напишете свой внутренний метод / транзакцию в другом классе или не перейдете к другому классу, а затем снова придете к вашему классу и затем напишите внутренний метод вложенной транскокации.
Подводя итог, весенние прокси делают не разрешайте сценарии, с которыми вы сталкиваетесь. вам необходимо написать второй метод транзакции в другом классе
7 ответов
Спецификация HTTP ( RFC 2616 ) имеет ряд применимых рекомендаций. Вот моя интерпретация:
- HTTP-код состояния
200 OKдля успешного PUT обновления для существующий ресурс. Тело ответа не требуется. (Согласно Раздел 9.6 ,204 Нет содержимогоеще более уместно.) - Код статуса HTTP
201 Создандля успешного PUT нового ресурс с наиболее конкретным URI для нового ресурса, возвращаемого в поле заголовка Location, и любые другие соответствующие URI и метаданные ресурса, отраженные в теле ответа. ( RFC 2616, раздел 10.2.2 ) - Код состояния HTTP
409 Конфликтдля PUT, который не выполнен из-за к модификации 3 3 , со списком различий между попыткой обновления и текущим ресурсом в ответе тело. ( RFC 2616, раздел 10.4.10 ) - Код состояния HTTP
400 неверный запросдля неудачного PUT, с текстом на естественном языке (например, английским) в теле ответа это объясняет, почему PUT не удалось. ( RFC 2616, раздел 10.4 )
В отличие от большинства ответов здесь, я на самом деле думаю, что PUT должен вернуть обновленный ресурс (в дополнение к HTTP-коду, конечно).
Причина, по которой вы хотели бы возвращать ресурс в качестве ответа для операции PUT, потому что когда вы отправляете представление ресурса на сервер, сервер также может применить некоторую обработку к этому ресурсу, поэтому клиент хотел бы знать, как выглядит этот ресурс после успешного завершения запроса , (в противном случае он должен будет выполнить еще один запрос GET).
В спецификации HTTP / 1.1 (раздел 9.6) обсуждаются соответствующие коды ответа / ошибки. Однако это не относится к содержанию ответа.
Чего бы вы ожидали? Простой код ответа HTTP (200 и т. Д.) Мне кажется простым и недвусмысленным.
Подобно тому, как пустое тело запроса соответствует первоначальной цели запроса GET, а пустое тело ответа соответствует первоначальной цели запроса PUT.
seems ok... though I'd think a rudimentary indication of success/failure/time posted/# bytes received/etc. would be preferable.
edit: I was thinking along the lines of data integrity and/or record-keeping; metadata such as an MD5 hash or timestamp for time received may be helpful for large datafiles.
Существует разница между заголовком и телом ответа HTTP. PUT никогда не должен возвращать тело, но должен возвращать код ответа в заголовке. Просто выберите 200, если это было успешно, и 4xx, если нет. Нет такого понятия, как нулевой код возврата. Почему вы хотите это сделать?