Вопрос по google-app-engine, get, http, http-status-codes, channel-api – HTTP Get с 204 нет содержимого: это нормально

33

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

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

Есть довольно хорошая статья о 204 кодах статуса, пожалуйста, найдите ее, используя следующую ссылку:blog.ploeh.dk/2013/04/30/... Aliaksei Maniuk

Ваш Ответ

4   ответа
3

и также будет работать.

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

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

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

5

которая представляет собой позиционный массив известной фиксированной длины, но с отверстиями.

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
Я просто хотел сказать, что твой пример красиво лаконичен. Отлично сработано. D. Visser
13

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

Целью GET является получение ресурса. Поэтому, хотя это разрешено, HTTP 204 не будетЭто лучший выбор, так как в ответе ожидается содержание.HTTP 404 не найден илиHTTP 410 ушел будет лучшим выбором, если сервер не сможет предоставить запрошенный ресурс.

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

УвидетьRFC для семантики GET.

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

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

Еще один хороший и хорошо документированный ответ. Congrats. statosdotcom
40
204 Нет содержимого

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

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

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

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

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

Похожие вопросы