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

153

  1. Согласно «идеологии REST», что должно быть в теле ответа для запросов PUT / POST / DELETE?

  2. А как насчет кодов возврата? Есть HTTP_OKдостаточно?

  3. В чем причина таких соглашений, если таковые имеются?

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

rest http post http-delete tuxSlayer
источник

Ответы:

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 в случае ошибок.

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