http - ошибка 444




Код состояния HTTP для обновления и удаления? (6)

RFC 2616 описывает, какие коды состояния использовать .

И нет, это не всегда 200.

Какой код состояния должен быть установлен для UPDATE ( PUT ) и DELETE (например, продукт успешно обновлен)?


В дополнение к 200 и 204, 205 (Сброс содержимого) может быть действительным ответом.

Сервер выполнил запрос, и пользовательский агент СЛЕДУЕТ сбросить вид документа, из-за которого запрос был отправлен ... [например] очистка формы, в которой вводится вход.


Вот несколько советов:

УДАЛЯТЬ

  • 200 (если вы хотите отправить некоторые дополнительные данные в ответ) или 204 (рекомендуется).

  • 202 Операция удалена еще не завершена.

  • Если ничего не нужно удалить, используйте 204 или 404 (операция DELETE идемпотент, удаление уже удаленного элемента выполняется успешно , поэтому вы можете вернуть 204 , но верно, что idempotent не обязательно подразумевает тот же ответ)

Другие ошибки:

  • 400 Bad Request (неверный синтаксис или плохой запрос - это странно, но возможно).
  • 401 Неавторизованная ошибка аутентификации
  • 403 Запрещено : сбой авторизации или недопустимый идентификатор приложения.
  • 405 не разрешено . Конечно.
  • 409 Конфликт ресурсов может быть возможен в сложных системах.
  • И 501 , 502 в случае ошибок.

ПОЛОЖИЛ

Если вы обновляете элемент коллекции

  • 200/204 по тем же причинам, что и DELETE выше.
  • 202, если операция еще не была выполнена.

Указанный элемент не существует:

  • PUT может быть 201 (если вы создали элемент, потому что это ваше поведение)
  • 404 Если вы не хотите создавать элементы через PUT.

  • 400 Bad Request (неверный синтаксис или плохой запрос чаще, чем в случае DELETE).

  • 401 Несанкционированный
  • 403 Запрещено : сбой аутентификации или недопустимый идентификатор приложения.
  • 405 не разрешено . Конечно.
  • 409 Конфликт ресурсов может быть возможен в сложных системах, как в DELETE.
  • 422 Непроцессный объект. Он помогает различать «неправильный запрос» (например, искаженный XML / JSON) и недопустимые значения полей
  • И 501 , 502 в случае ошибок.

Для запроса PUT : HTTP 200 или HTTP 204 должен означать, что «ресурс обновлен успешно».

Для запроса DELETE : HTTP 200 или HTTP 204 должен означать, что «ресурс удален успешно». HTTP 202 также может быть возвращен, что означало бы, что инструкция была принята сервером, а «ресурс был помечен для удаления».

9.6 PUT

Если существующий ресурс изменен, для подтверждения успешного завершения запроса необходимо отправить код ответа 200 (OK) или 204 (Нет содержимого). ДОЛЖЕН быть отправлен.

9.7 УДАЛИТЬ

Успешный ответ ДОЛЖЕН быть 200 (ОК), если ответ включает объект, описывающий статус, 202 (Принято), если действие еще не было принято, или 204 (Нет содержимого), если действие было принято, но ответ не включает сущность.

Источник: w3.org: Определения метода HTTP / 1.1

HTTP 200 OK: стандартный ответ для успешных HTTP-запросов. Фактический ответ будет зависеть от используемого метода запроса.

HTTP 204 Нет содержимого: сервер успешно обработал запрос, но не возвращает какой-либо контент

Источник: список кодов состояния HTTP: 2xx Success


Короткий ответ: для PUT и DELETE вы должны отправить либо 200 (OK), либо 204 (без содержимого).

Длинный ответ: вот полная схема принятия решения (нажмите, чтобы увеличить).

Источник: https://github.com/for-GET/http-decision-diagram


Поскольку вопрос возникает, если DELETE «должен» вернуть 200 против 204, стоит подумать, что некоторые люди рекомендуют возвращать сущность со ссылками, поэтому предпочтение отдается 200 .

«Вместо того, чтобы возвращать 204 (без контента), API должен быть полезен и предлагать места для перехода. В этом примере я думаю, что одна очевидная ссылка для этого -« «где-то.com/container/» (минус «ресурс») »- контейнер, из которого клиент просто удалил ресурс. Возможно, клиент хочет удалить больше ресурсов, так что это будет полезной ссылкой ».

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

Если клиент встречает ответ 204, он может либо отказаться, перейти к точке входа API, либо вернуться к предыдущему ресурсу, который он посетил. Ни один из вариантов не является особенно хорошим.

Лично я бы не сказал, что 204 ошибается (и автор не говорит «раздражает»), потому что хорошее кэширование на стороне клиента имеет много преимуществ. Лучше всего быть последовательным в любом случае.





http-status-codes