Какие вызовы REST PUT / POST / DELETE должны возвращаться по соглашению?

153

Согласно «идеологии REST», что должно быть в теле ответа для запросов PUT / POST / DELETE?
А как насчет кодов возврата? Есть HTTP_OKдостаточно?
В чем причина таких соглашений, если таковые имеются?

Я нашел хороший пост, описывающий различия POST / PUT: POST против PUT, но он все еще не отвечает на мой вопрос.

130

Простите за легкомысленность, но если вы выполняете REST поверх HTTP, тогда RFC7231 точно описывает поведение, ожидаемое от GET, PUT, POST и DELETE.

Обновление (3 июля 14 года):
HTTP-спецификация намеренно не определяет, что возвращается из POST или DELETE. Спецификация определяет только то, что должно быть определено. Остальное оставлено на усмотрение исполнителя.

— Даррел Миллер
источник

9

@tuxslayer Я рад, что ты не думал, что я просто пытался быть скупым. Многие люди думают, что REST добавляет требования к дополнению поверх методов HTTP. Однако это не так. Существуют дополнительные ограничения, но они не влияют на поведение методов HTTP. RFC2616, безусловно, руководство для подражания.

— Даррел Миллер

4

Я ценю ссылку. :) Это заставило меня остановиться и подумать об инструменте, который я использую. Прочитав ваш пост и RFC, я обнаружил, что обращаюсь к RFC до конца ночи. Это помогло мне представить процесс в первую очередь как процесс HTTP, а затем - процесс отдыха. Очень признателен.

— Перри Тью

4

@PerryTew Теперь вы можете перейти по адресу tools.ietf.org/wg/httpbis и посмотреть текущую версию HTTP-спецификации, которая в настоящее время пересматривается. Наслаждайтесь!

— Даррел Миллер

12

Возможно, мне просто нужно больше спать, но я не могу найти точную информацию, которую ОП запросил в RFC. Каким должно быть тело для ответа POST или DELETE?

— Кэм Джексон

9

Ну, это примерно так же ясно, как грязь. Возможно, будет полезна дополнительная информация в ответе. Особенно, когда эта ссылка мертва.

— Дуг Молинью

25

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

Для PUT я бы вернул тот же вид, который вы получили бы, если бы вы сразу же получили GET; это приведет к 200 (ну, конечно, если рендеринг будет успешным). Для POST я бы сделал перенаправление на созданный ресурс (при условии, что вы выполняете операцию создания; если нет, просто верните результаты); код для успешного создания - 201, который на самом деле является единственным HTTP-кодом для перенаправления, которого нет в диапазоне 300.

Я никогда не был рад тому, что DELETE должен вернуть (мой код в настоящее время выдает HTTP 204 и пустое тело в этом случае).

— Donal Fellows
источник

1

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

— Лобати

1

@lobati Я думаю, важно отметить, что отправка нескольких идентичных запросов PUT должна иметь точно такой же результат, как и отправка только одного из тех же запросов PUT. Возможно, проблема, которую вы поднимаете, сейчас менее важна, учитывая вышесказанное?

— Иан

3

@ Не совсем. Проблема в том, что если что-то позже обновит запись, вы не захотите, чтобы она отправила другой PUTзапрос, приводящий к возвращению данных. Например, если два человека ссылаются на одну и ту же страницу, один обновляет, а другой обновляет, если первый обновляется, чтобы увидеть результат, это в конечном итоге приводит к тому, что вещи возвращаются до того, как второй сделал их изменения.

— Лобати

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

— Люк Пуплетт

3

Создание ресурса обычно сопоставляется с POST, и это должно возвращать местоположение нового ресурса; например, в скаффолде Rails CREATE будет перенаправлять на SHOW для вновь созданного ресурса. Тот же самый подход может иметь смысл для обновления (PUT), но это менее условно; обновление должно только указывать на успех. Удаление, вероятно, должно указывать только на успех; если вы хотите перенаправить, возвращение списка ресурсов, вероятно, имеет смысл.

Успех может быть указан HTTP_OK, да.

Единственное строгое правило в том, что я сказал выше, это то, что CREATE должен возвращать местоположение нового ресурса. Это кажется легкой задачей для меня; вполне логично, что клиент должен иметь возможность доступа к новому элементу.

— Джейкоб Маттисон
источник

2

Вы на самом деле перепутали PUT и POST. POST используется для создания, PUT используется для обновления (и создания). Также стоит отметить, что PUT должен быть идемпотентом, а POST - нет.

— Стиви

Идемпотентная команда должна работать правильно, сколько бы раз вы ее не запускали. Таким образом, вы должны иметь возможность делать одно и то же PUT несколько раз, чтобы применить одно и то же «обновление» без каких-либо негативных побочных эффектов.

— Джейкоб Мэттисон

1

По RFC7231 это не имеет значения и может быть пустым

Как мы реализуем стандартное решение json api в проекте:

post / put: выводит атрибуты объекта как в get (поле filter / Relations применяется так же)

delete: данные содержат только null (для представления отсутствующего объекта)

статус для стандартного удаления: 200

— Мариус Гри
источник

0

Мне нравится, что Alfonso Tienda отвечает из кода состояния HTTP для обновления и удаления?

Вот несколько советов:

УДАЛИТЬ

200 (если вы хотите отправить некоторые дополнительные данные в ответе) или 204 (рекомендуется).

202 Операция удалена, еще не было совершено.

Если нечего удалять, используйте 204 или 404 (операция УДАЛИТЬ идемпотентна, удаление уже удаленного элемента - операция успешна , поэтому вы можете вернуть 204 , но это правда, что идемпотент не обязательно подразумевает тот же ответ)

Другие ошибки:

400 Bad Request (неправильный синтаксис или неверный запрос странный, но возможный).

401 Ошибка неавторизованной аутентификации

403 Запрещено : ошибка авторизации или неверный идентификатор приложения.

405 Не разрешено . Конечно.

409 Конфликт ресурсов возможен в сложных системах.

И 501 , 502 в случае ошибок.

СТАВИТЬ

Если вы обновляете элемент коллекции

200/204 по тем же причинам, что и УДАЛИТЬ выше.

202, если операция еще не была совершена.

Указанный элемент не существует:

PUT может быть 201 (если вы создали элемент, потому что это ваше поведение)

404 Если вы не хотите создавать элементы через PUT.

400 Bad Request (неправильный синтаксис или неправильный запрос, более распространенный, чем в случае DELETE).

401 Несанкционированный

403 Запрещено : ошибка аутентификации или неверный идентификатор приложения.

405 Не разрешено . Конечно.

409 Конфликт ресурсов возможен в сложных системах, например, в DELETE.

422 Необработанный объект Помогает различить «неверный запрос» (например, неверный XML / JSON) и недопустимые значения полей

И 501 , 502 в случае ошибок.

— Рябченко Александр
источник