HTTP Get с 204 без содержимого: это нормально?

Является ли запрос HTTP GET нормальным явлением получение ответа с кодом состояния 204 - No Content? Мол, это семантически правильно в отношении того, что должен выполнять HTTP GET? Я знаю, что 204 - No Content нормально для HTTP-запроса POST. Для запроса GET, если данные не должны быть отправлены обратно, подходит ли код состояния 204? Должен ли я использовать 404 или просто придерживаться 200 для успеха, но получить пустой ответ?

Пример использования для этого вопроса - приложение Java, которое я пишу для Google App Engine. Я отправляю запрос сервлету, но данные, которые нужно отправить обратно клиенту, будут переданы через сокет Channel API, а не в HTTP-ответе. В настоящее время мой клиент отправляет POST без содержимого в теле запроса и ожидает ответа 204 от сервлета перед опросом сокета Channel API. Поскольку в теле запроса нет данных, которые я отправляю, я обсуждаю, имеет ли смысл отправлять GET вместо POST.


http get google-app-engine http-status-codes channel-api
person ecbrodie    schedule 09.10.2012    source источник
comment
Есть неплохая статья о коде статуса 204, ее можно найти по следующей ссылке: blog.ploeh.dk/2013/04/30/   -  person Aliaksei Maniuk    schedule 24.07.2017

Ответы (5)


arrow_upward
74
arrow_downward

204 Нет содержимого

Сервер выполнил запрос, но не должен возвращать тело объекта и может захотеть вернуть обновленную метаинформацию. Ответ МОЖЕТ включать новую или обновленную метаинформацию в форме заголовков объектов, которые, если они присутствуют, ДОЛЖНЫ быть связаны с запрошенным вариантом.

Согласно части RFC для кода состояния 204, мне кажется, что это правильный выбор для Получить запрос.

404 Not Found, 200 OK с пустым телом и 204 No Content имеют совершенно разное значение, иногда мы не можем использовать правильный код состояния, но нарушаем правила, и они вернутся, чтобы укусить вас однажды или позже. Итак, если вы можете использовать правильный код состояния, используйте его!

Я думаю, что выбор GET или POST очень личный, поскольку они оба будут выполнять свою работу, но я бы рекомендовал вам сохранить POST вместо GET по двум причинам:

  • Вы хотите, чтобы другая часть (сервлет, если я правильно понимаю) выполняла действие, а не извлекала из него какие-то данные.
  • По умолчанию запросы GET кэшируются, если в URL-адресе нет параметров, а POST - нет.
person Satevis    schedule 09.10.2012
comment
Я не знал, что GET кэшируется, а POST - нет; хороший лакомый кусочек информации для изучения. Спасибо. - person ecbrodie; 10.10.2012
comment
@ecbrodie Пожалуйста, вы можете найти дополнительную информацию о кешировании для запросов GET и POST здесь - person Satevis; 10.10.2012

arrow_upward
67
arrow_downward

Я использую GET / 204 с коллекцией RESTful, которая представляет собой позиционный массив известной фиксированной длины, но с отверстиями.

GET /items
    200: ["a", "b", null]

GET /items/0
    200: "a"

GET /items/1
    200: "b"

GET /items/2
    204:

GET /items/3
    404: Not Found
person Steve Mitchell    schedule 30.12.2017
comment
Я просто хотел сказать, что ваш пример очень лаконичен. Отличная работа. - person D. Visser; 09.01.2019
comment
Вы бы использовали его, если бы не позиционный массив, а, например, строковый поиск? / элемент / а / элемент / с - person aQ123; 17.04.2020

arrow_upward
20
arrow_downward

Ваша текущая комбинация POST с ответом HTTP 204 в порядке.

Использование POST в качестве универсальной замены для GET не поддерживается RFC, поскольку каждый из них имеет свою конкретную цель и семантику.

Цель GET - получить ресурс. Следовательно, хотя он и разрешен, HTTP 204 не будет лучшим выбором, поскольку в ответе ожидается содержимое. HTTP 404 Not Found или HTTP 410 Gone был бы лучшим выбором, если бы сервер не смог предоставить запрошенный ресурс.

RFC также специально вызывает HTTP 204 как подходящий ответ для PUT, POST и DELETE, но опускает его для GET.

См. RFC для семантики GET.

Существуют и другие коды ответа, которые также могут быть возвращены, указывая на отсутствие содержимого, что было бы более подходящим, чем HTTP 204.

Например, для условного GET вы можете получить HTTP 304 Not Modified ответ, который не будет содержать основного содержимого.

person Russ Jackson    schedule 26.08.2014
comment
Еще один хороший и хорошо задокументированный ответ. Поздравляю. - person statosdotcom; 30.01.2017

arrow_upward
10
arrow_downward

POST / GET с 204 на первый взгляд кажется прекрасным и также будет работать.

В документации указано, 2xx - этот класс кодов состояния указывает, что действие, запрошенное клиентом, было получено, понято, принято и успешно обработано. тогда как 4xx - класс кода состояния 4xx предназначен для ситуаций, в которых клиент, похоже, допустил ошибку.

Поскольку запрос был успешно получен, понят и обработан на сервере. В результате ресурс не был найден. Таким образом, в данном случае это не было ошибкой на стороне клиента или клиент не совершил ошибку.

Следовательно, это должен быть код серии 2xx, а не 4xx. Отправка 204 (без содержимого) в этом случае будет лучше, чем ответ 404 или 410.

person iosCurator    schedule 22.12.2016

arrow_upward
0
arrow_downward

Http GET, возвращающий 204, совершенно нормально, так же как и 404.

Важно то, что вы определили стандарты / рекомендации по дизайну для своего API, чтобы все ваши конечные точки использовали коды состояния единообразно.

Например:

  • вы можете указать, что конечная точка GET, которая возвращает коллекцию ресурсов, вернет 204, если коллекция пуста. В этом случае GET /complaints/year/2019/month/04 может вернуть 204, если в апреле 2019 г. не было подано жалоб. Это не ошибка на стороне клиента, поэтому мы возвращаем код состояния успеха (204). OTOH, GET /complaints/12345 может вернуть 404, если номер жалобы 12345 не существует.
  • если ваш API использует HATEOAS, 204, вероятно, будет плохой идеей, потому что ответ должен содержать ссылки для перехода к другим состояниям.
person Paulo Merson    schedule 18.11.2020