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

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

1026
http http-status-codes

8 ответов

на PUT запрос: > > до 200 или HTTP 204 должно означать "ресурс успешно обновлена".

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

9.6 Положи

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

9.7 удалить

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

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

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

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

источник: список кодов состояния HTTP: 2xx Успех

1592

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

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

HTTP 1.1 decision diagram

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

731

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

удалить

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

  • 202 операция удалена еще не была зафиксирована.

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

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

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

поставить

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

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

ссылочный элемент не существует:

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

  • 404 если вы не хотите создавать элементы через КЛАСТЬ.

  • 400 Неверный Запрос (неправильный синтаксис или плохой запрос чаще, чем в случае удаления).

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

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

и не всегда 200.

13

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

сервер выполнил запрос, и агент пользователя должен сбросить представление документа, которое вызвало отправку запроса ... [например] очистка формы, в которой вводится информация.

7

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

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

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

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

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

6

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

2

при изменении ресурса код ответа должен быть 200 ("OK"). Если состояние ресурса изменяется таким образом, что URI изменяется на ресурс (например, учетная запись пользователя переименовывается),код ответа 301 ("перемещено навсегда") и заголовок местоположения должен предоставить новый URI.

когда объект удаляется, код ответа должно быть 200 ("OK").

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

-1