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

1375

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

http http-status-codes xpepermint
источник

Ответы:

2104

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

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

ПОЛОЖИЛ

Если существующий ресурс изменен, то должны быть отправлены либо коды ответа 200 (ОК), либо 204 (Нет содержимого)>, чтобы указать успешное завершение запроса.

УДАЛЯТЬ

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

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

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

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

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

Даниэль Вассалло
источник
40
Очень полезный пост! Однако мне интересно, каким должен быть код состояния HTTP, если запрос, отправленный клиентом, действителен (DELETE mySite / entity / 123 ), а сущность для удаления не существует.
Мартин
64
@Martin: В этом случае служба должна возвращать HTTP 404. Строго говоря, DELETE или запрос GET для ресурса , который не существует в не «действительный» запрос - то есть. клиент не должен повторять этот запрос, потому что он никогда не будет успешным ... Протокол HTTP определяет 2 категории проблем: проблемы с кодом состояния 4xx, когда клиент должен изменить запрос перед повторной попыткой, и проблемы со статусом 5xx код, который указывает, что служба столкнулась с проблемой, и клиент должен / может повторить тот же самый точный запрос, не меняя его.
Даниэль Вассалло
17
@JeffMartin Это может быть так с точки зрения пользователя, но что касается сервера, если ресурс не существует, сервер должен вернуть 404.
Randolpho
17
@Randolpho, Idempotence - это все о получении одного и того же результата, независимо от того, вызываете ли вы операцию один или несколько раз. Клиент просит вас убедиться, что ресурс удален. Какая выгода от возвращения 404? Почему это нужно знать в любом случае? Теперь клиентская логика должна обрабатывать два отдельных кода ответа вместо одного.
Гили
26
@Gili: возможно, вики объяснит лучше: методы PUT и DELETE определены как идемпотентные ... обратите внимание, что идемпотентность относится к состоянию системы после выполнения запроса, поэтому во время действия, выполняемого сервером (например, удаление записи ) или код ответа, который он возвращает, может отличаться при последующих запросах, состояние системы будет одинаковым каждый раз.
Рандольфо
859

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

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

Схема принятия решения HTTP 1.1

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

ЯegDwight
источник
37
Диаграмма потрясающая. Существует ли версия для печати с более высоким разрешением?
КиКи
1
В контексте POST существующего ресурса, другое обсуждение SO ( stackoverflow.com/questions/3825990/… ) предлагает отправить 409 Conflict или 302 Found вместо добавления контента.
Коппор
7
Мне любопытно, если ответ 204 и 200 после удаления должен быть обратным, и если они верны, как есть, почему? Удаляется? -> Ответ включает в себя сущность? -> да -> 204 Нет контента; нет -> 200 OK
Matth
62
Обновленная версия изображения находится здесь: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
zaius
19
Отсутствует патч.
дореми
151

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

УДАЛЯТЬ

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

  • 202 Операция удалена, еще не было совершено.

  • Если нечего удалять, используйте 204 или 404 (операция УДАЛИТЬ идемпотентна, удаление уже удаленного элемента - операция успешна , поэтому вы можете вернуть 204 , но это правда, что идемпотент не обязательно подразумевает тот же ответ)

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

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

ПОЛОЖИЛ

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

  • 200/204 по тем же причинам, что и УДАЛИТЬ выше.
  • 202, если операция еще не была совершена.

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

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

  • 404 Если вы не хотите создавать элементы через PUT.

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

  • 401 Несанкционированный
  • 403 Запрещено : ошибка аутентификации или неверный идентификатор приложения.
  • 405 Не разрешено . Конечно.
  • 409 Конфликт ресурсов возможен в сложных системах, например, в DELETE.
  • 422 Непроцессируемый объект Помогает различить «неверный запрос» (например, неверный XML / JSON) и недопустимые значения полей
  • И 501 , 502 в случае ошибок.
Альфонсо Тиенда
источник
7
Этот ответ почти целиком состоит из двух больших цитат, но авторства здесь нет. Откуда вы цитируете?
Квентин
Является ли 204 правильным статусом для возврата для запроса PUT, если состояние не изменяется эффективно? Например, вы просите деактивировать пользователя, но он уже неактивен.
Ε Г И І И О
Запрос PUT идемпотентен, поэтому вы можете вернуть 204, потому что объект изменился в системе. PUT - это не PATCH, поэтому вы не уверены, какое поле вы хотите изменить. Вы можете отправить обратно 501 - 502, если ваш дизайн должен знать, был ли объект точно таким же, как объект в запросе, но ... мне это не очень нравится .. Я предпочитаю 204 или, если вы хотите деактивировать пользователя, не меняя больше полей, возможно, вы можете использовать PATCH.
Альфонсо Тиенда
1
Я бы добавил HTTP 422 Unprocessable Entity. Это помогает различать «неверный запрос» (например, некорректный XML / JSON) и недопустимые значения полей.
vdboor
10

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

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

PJE
источник
6

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

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

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

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

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

Строймеханизация
источник
6

Вот код состояния, который вы должны знать для своих знаний.

1XX Информационные ответы

  • 100 Продолжить
  • 101 протокол переключения
  • 102 Обработка
  • 103 ранних намеков

2XX Успех

  • 200 ОК
  • 201 Создано
  • 202 Принято
  • 203 Неофициальная информация
  • 204 Нет содержимого
  • 205 Сбросить содержимое
  • 206 Частичное содержание
  • 207 мульти-статус
  • 208 уже сообщили
  • 226 IM Используется

3XX Redirection

  • 300 множественных вариантов
  • 301 перемещено навсегда
  • 302 найдено
  • 303 См. Другое
  • 304 Не модифицировано
  • 305 Использовать прокси
  • 306 Switch Proxy
  • 307 Временный редирект
  • 308 постоянный редирект

Ошибки клиента 4XX

  • 400 плохих запросов
  • 401 Несанкционированный
  • 402 Требуется оплата
  • 403 Запрещено
  • 404 не найден
  • 405 метод не разрешен
  • 406 неприемлемо
  • 407 Proxy Authentication Required
  • 408 Время ожидания запроса
  • 409 конфликт
  • 410 ушел
  • 411 длина требуется
  • 412 Не выполнено предварительное условие
  • 413 Слишком большая нагрузка
  • 414 URI слишком длинный
  • 415 неподдерживаемый тип носителя
  • 416 Неудовлетворительный диапазон
  • 417 Ожидание не удалось
  • 418 я чайник
  • 420 Ошибка метода
  • 421 неправильный запрос
  • 422 необработанного объекта
  • 423 заблокирован
  • 424 Неудачная зависимость
  • 426 Требуется обновление
  • 428 Требуется предварительное условие
  • 429 слишком много запросов
  • 431 слишком большие поля заголовка запроса
  • 451 недоступен по юридическим причинам

5XX Ошибки сервера

  • 500 Внутренняя ошибка сервера
  • 501 не реализовано
  • 502 Bad Gateway
  • 503 Сервис недоступен
  • Тайм-аут шлюза 504
  • Http-версия 505 не поддерживается
  • 506 Varient Также ведутся переговоры
  • 507 Недостаточно памяти
  • 508 петля обнаружена
  • 510 не продлен
  • 511 Требуется сетевая аутентификация
принц
источник
3

В июне 2014 RFC7231 устарел RFC2616 . Если вы выполняете REST через HTTP, тогда RFC7231 точно описывает поведение, ожидаемое от GET, PUT, POST и DELETE.

Иван
источник
-1

Когда ресурс изменяется, код ответа должен быть 200 («ОК») . Если состояние ресурса изменяется таким образом, что URI изменяется на ресурс (например, учетная запись пользователя переименовывается), код ответа - 301 («Перемещено постоянно»), а заголовок Location должен предоставлять новый URI.

Когда объект удаляется, код ответа должен быть 200 («ОК»).

Перейдите по ссылке ниже для получения более подробной информации - код состояния для отдыха

Ашутош Кумар
источник