Який код статусу слід встановити для UPDATE( PUT) та DELETE(наприклад, продукт успішно оновлений)?
Код статусу HTTP для оновлення та видалення?
Відповіді:
Для запиту 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 Успіх
40
Дуже корисний пост! Однак мені цікаво, яким повинен бути код статусу HTTP - це запит, надісланий клієнтом, дійсний (DELETE mySite / entitet / 123 ), а сутність для видалення не існує.
—
Мартін
@Martin: У такому випадку сервіс повинен повернути HTTP 404. Строго кажучи, DELETE або GET-запит на ресурс, який не існує, не є "дійсним" запитом - тобто. клієнт не повинен повторно намагатись із цим запитом, тому що він ніколи не матиме успіху ... Протокол HTTP визначає 2 категорії проблем - ті, що мають код статусу 4xx, де клієнт повинен змінити запит перед його повторним повторенням, і ті, які мають статус 5xx код, який вказує на те, що сервіс зіткнувся з проблемою і клієнт повинен / міг би повторити той самий точний запит, не змінюючи його.
—
Даніель Вассалло
@JeffMartin Це може бути так з точки зору користувача, але що стосується сервера, якщо ресурсу не існує, сервер повинен повернути 404.
—
Randolpho
@Randolpho, Idempotence - це результат отримання однакового результату, незалежно від того, ви посилаєтесь на операцію один чи кілька разів. Клієнт просить вас забезпечити видалення ресурсу. Яка вигода від повернення 404? Чому це потрібно знати в будь-якому випадку? Тепер клієнтська логіка повинна обробляти два окремі коди відповідей замість одного.
—
Гілі
@Gili: можливо, wiki пояснить краще: Методи PUT і DELETE визначені як idempotent ... зауважте, що idempotence посилається на стан системи після завершення запиту, тому поки діятиме сервер (наприклад, видалення запису ) або код відповіді, який він повертає, може бути різним при наступних запитах, стан системи буде однаковим кожен раз.
—
Рендольфо
Коротка відповідь: і для PUT, і для DELETE вам слід надіслати або 200 (ОК), або 204 (Без вмісту).
Довга відповідь: ось повна схема рішення (натисніть, щоб збільшити).
Діаграма дивовижна. Чи є версія для більш високої роздільної здатності для друку?
—
KiKi
У контексті POST існуючого ресурсу, інша дискусія щодо SO ( stackoverflow.com/questions/3825990/… ) пропонує надіслати 409 Conflict або 302 Found замість додавання вмісту.
—
коппор
Мені цікаво, якщо відповідь 204 і 200 після того, як відбувається видалення, слід змінити, і якщо вони є правильними, як це, чому? Видалено? -> Відповідь включає сутність? -> так -> 204 Без вмісту; ні -> 200 ОК
—
мат.
Оновлена версія зображення тут: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
—
zaius
У ньому відсутній PATCH.
—
доремі
Ось кілька порад:
УДАЛИТИ
200 (якщо потрібно надіслати деякі додаткові дані у відповіді) або 204 (рекомендується).
202 Операція видалена ще не здійснена.
Якщо нічого не можна видалити, використовуйте 204 або 404 (операція DELETE ідентична, видалення вже видаленого елемента є успішною , тому ви можете повернути 204 , але це правда, що idempotent не обов'язково означає той самий відгук)
Інші помилки:
- 400 Неправильний запит (неправильний синтаксис або поганий запит є дивним, але можливим).
- 401 Несанкціонована помилка аутентифікації
- 403 Заборонено : помилка авторизації або недійсний ідентифікатор програми.
- 405 Не дозволено . Звичайно.
- 409 Конфлікт ресурсів можливий у складних системах.
- І 501 , 502 у разі помилок.
ПУТ
Якщо ви оновлюєте елемент колекції
- 200/204 з тих же причин, що і ВИДАЛИТИ вище.
- 202, якщо операція ще не здійснена.
Посиланий елемент не існує:
- PUT може бути 201 (якщо ви створили елемент, тому що це ваша поведінка)
404 Якщо ви не хочете створювати елементи через PUT.
400 Неправильний запит (неправильний синтаксис або поганий запит, частіше, ніж у випадку DELETE).
- 401 Несанкціонований
- 403 Заборонено : помилка аутентифікації або недійсний ідентифікатор програми.
- 405 Не дозволено . Звичайно.
- 409 Конфлікт ресурсів може бути можливим у складних системах, як у DELETE.
- 422 Unprocessable об'єкт Це допомагає відрізнити «Невірний запит» (наприклад , невірний формат XML / JSON) і неприпустимі значення поля
- І 501 , 502 у разі помилок.
Ця відповідь майже повністю складається з двох великих цитат, але атрибуції немає. Звідки ви цитуєте?
—
Квентін
Чи є 204 належним статусом для повернення запиту PUT, якщо стан не змінено ефективно? Наприклад, ви просите деактивувати користувача, але він вже неактивний.
—
Ε Г І І І О
Запит PUT ідентичний, тому ви можете повернути номер 204, оскільки об'єкт змінився в системі. PUT не PATCH, тому ви не впевнені, яке поле ви хочете змінити. Ви можете відправити назад 501 - 502, якщо ваш дизайн повинен знати, чи об’єкт був точно таким, як об’єкт у запиті, але ... Мені це не дуже подобається .. Я вважаю за краще 204 або, якщо ви хочете деактивуйте користувача, не змінюючи більше полів, можливо, ви можете використовувати PATCH.
—
Альфонсо Тієнда
Я додав би HTTP 422 Unprocessable Entity. Це допомагає розрізнити "неправильний запит" (наприклад, неправильно сформований XML / JSON) та недійсні значення поля.
—
vdboor
RFC 2616 описує, які коди статусу використовувати .
І ні, це не завжди 200.
На додаток до 200 та 204, 205 (Скинути вміст) може бути коректною відповіддю.
Сервер виконав запит, і користувальницький агент ДОЛЖНО скинути перегляд документа, який спричинив надсилання запиту ... [наприклад] очищення форми, в якій вводиться вхід.
Оскільки питання заглиблюється в те, чи DELETE "повинен" повернути 200 проти 204 , варто врахувати, що деякі люди рекомендують повернути об'єкт із посиланнями, тому перевага для 200 .
"Замість того, щоб повернути 204 (Без вмісту), API повинен бути корисним і запропонувати місця, де можна перейти. У цьому прикладі я думаю, що одне очевидне посилання, яке потрібно надати, - це" "Where.com/container/ '(мінус' ресурс ') " - контейнер, з якого клієнт щойно видалив ресурс. Можливо, клієнт бажає видалити більше ресурсів, щоб це було корисним посиланням. "
http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204- responses/
Якщо клієнт стикається з відповіддю 204, він може або відмовитися, перейти до точки входу API, або повернутися до попереднього ресурсу, який він відвідав. Жоден варіант не є особливо хорошим.
Особисто я б не сказав, що 204 - це неправильно (також не автор, він каже "дратує"), тому що хороший кешування на стороні клієнта має багато переваг. Найкраще - бути послідовними в будь-якому випадку.
Ось код коду статусу, який ви повинні знати для свого знання.
Інформаційні відповіді 1XX
- 100 Продовжуйте
- 101 Переключення протоколів
- 102 Обробка
- 103 Ранні підказки
2XX Успіх
- 200 ОК
- 201 Створено
- 202 Прийнято
- 203 Неавторитетна інформація
- 204 Немає вмісту
- 205 Скидання вмісту
- 206 Частковий зміст
- 207 Багатосторонність
- 208 Вже повідомлено
- 226 IM Використовується
Перенаправлення 3XX
- 300 варіантів
- 301 Переїхав постійно
- 302 Знайдено
- 303 Див. Інше
- 304 Не змінено
- 305 Використовуйте проксі
- 306 Комутаційний проксі
- 307 Тимчасовий перенаправлення
- 308 Постійний перенаправлення
Помилки клієнта 4XX
- 400 Поганий запит
- 401 Несанкціонований
- 402 Потрібна оплата
- 403 Заборонено
- 404 Не знайдено
- 405 Метод не дозволений
- 406 Неприйнятно
- 407 Необхідна перевірка справжності проксі
- 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 Поганий шлюз
- 503 Сервіс недоступний
- Тайм-аут 504 шлюзу
- Версія 505 Http не підтримується
- 506 Варіант Також домовляйтесь
- 507 Недостатнє зберігання
- 508 Петля Виявлено
- 510 Не розширений
- 511 Network Authentication Required
Коли ресурс буде змінено, код відповіді повинен бути 200 ("ОК") . Якщо стан ресурсу змінюється таким чином, що змінює URI на ресурс (наприклад, перейменований обліковий запис користувача), код відповіді - 301 ("Переміщений постійно"), а заголовок Location повинен надавати новий URI.
Коли об’єкт видалено, код відповіді повинен бути 200 ("ОК").
Перейдіть за посиланням нижче, щоб отримати детальну інформацію - код статусу для відпочинку