HTTP Get with 204 No Content: Это нормально

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

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

Ответ 1

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

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

В соответствии с частью RFC для кода состояния 204, мне кажется правильным выбор для запроса GET.

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

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

Вы хотите, чтобы другая часть (сервлет, если я правильно понял), чтобы выполнить действие, не извлекает из него некоторые данные.
По умолчанию запросы GET можно кэшировать, если в URL нет параметров, POST - нет.

Ответ 2

Ваша текущая комбинация 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, который не содержит содержимого тела.

Ответ 3

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

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

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

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

Ответ 4

Я использую 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