Согласно идее REST, что должно быть в теле ответа для запросов PUT/POST/DELETE?
Как насчет кодов возврата? Достаточно ли HTTP_OK?
В чем причина таких соглашений, если таковые имеются?
Я нашел хорошую статью с описанием различий POST/PUT: POST vs PUT Но он все еще не отвечает на мой вопрос.
Простите за легкомысленность, но если вы выполняете REST поверх HTTP, тогда RFC7231 точно описывает поведение, ожидаемое от GET, PUT, POST и DELETE.
Обновление (3 июля 14 года):
Спецификация HTTP намеренно не определяет, что возвращается из POST или DELETE. Спецификация определяет только то, что должно быть определено. Остальное оставлено на усмотрение исполнителя.
В целом, соглашения "думают, что вы просто доставляете веб-страницы".
Для PUT я вернул бы тот же вид, который вы получили бы, если бы вы сделали GET сразу после; что приведет к 200 (ну, если, конечно, рендеринг будет успешным). Для POST я сделал бы перенаправление на созданный ресурс (если вы делаете операцию создания, а если нет, просто возвращайте результаты); код для успешного создания - это 201, который действительно является единственным HTTP-кодом для перенаправления, который не находится в диапазоне 300.
Я никогда не был доволен тем, что должен вернуть DELETE (мой код в настоящее время создает HTTP 204 и пустые тела в этом случае).
Создание ресурса обычно сопоставляется с POST, и это должно возвращать местоположение нового ресурса; например, в Rails-эшафоте CREATE будет перенаправляться на SHOW для вновь созданного ресурса. Такой же подход может иметь смысл для обновления (PUT), но это меньше, чем конвенция; обновление должно указывать только на успех. Удаление, вероятно, должно указывать только на успех; если вы хотите перенаправить, то, скорее всего, наиболее вероятно, вернет СПИСОК ресурсов.
Успех может быть указан HTTP_OK, да.
Единственное жесткое правило в том, что я сказал выше, заключается в том, что CREATE должен вернуть местоположение нового ресурса. Для меня это кажется просто бесполезным; имеет смысл, что клиент должен будет иметь доступ к новому элементу.
По RFC7231 это не имеет значения и может быть пустым
Как мы реализуем стандартное решение json api в проекте:
post/put: выводит атрибуты объекта как в get (поле фильтра/отношения применяется то же самое)
delete: данные содержат только null (для представления отсутствующего объекта)
статус для стандартного удаления: 200