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

Question

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

2. А как насчет кодов возврата? Достаточно ли HTTP_OK?

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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