Код статусу HTTP для часткового успішного запиту

115

У мене є додаток, який надсилає повідомлення користувачам. У запиті на повідомлення передається рядок XML, який складається з усіх користувачів, які повинні отримати саме це повідомлення. Якщо когось із користувачів у списку немає, я повертаю список зниклих користувачів назад для клієнта для подальшої оцінки.

Тепер я запитую себе, який би був правильний код статусу для програми, вказуючи, що запит прийнято, але є речі, які неможливо зробити.

Проблему можна було б уникнути, якби не було дозволено включати відсутніх користувачів до списку. Тоді спроба надсилання просто отримає помилку 4xx. Але немає сенсу формувати API таким чином. З іншого боку, я можу вважати умову помилки виключно конкретною програмою. Але відправити 200 просто не вважає себе правильним. І було б непогано дати клієнту підказку, коли глибоко зазирнути у відповідь на помилку. наприклад, щоб уникнути надсилання повідомлень цим користувачам знову і знову

http rest http-status-codes

— Норберт Хартл
джерело

66

Я займався дуже схожим питанням. У цьому випадку я повернув a

207 Багатозначний статус

Тепер це не суворий HTTP, він є частиною розширення WebDAV, тому якщо ви також не маєте контролю над клієнтом, то це не добре для вас. Якщо ви так, можете зробити щось подібне:

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D='DAV:'>
     <D:response>
       <D:user>user-123</D:user>
       <D:status>success</D:status>
     </D:response>
     <D:response>
       <D:user>user-789</D:user>
       <D:status>failure</D:status>
     </D:response>
   </D:multistatus>

Але знову ж таки, це розширення HTTP, і вам потрібно мати контроль над клієнтом.

— Кайлар
джерело

3

Я думав про використання цього, але мені це було не зовсім комфортно. Дякую!

— Норберт Хартл

Приємно в тому, що ви можете повернути стільки або мало відповідних даних, скільки хочете - що особливо корисно для наборів змішаних даних, тобто: де деякі не вдається, а деякі проходять.

— Кайлар

Я розумію. Я просто намагаюся уникати додаткового рівня обробки статусу (що не приємно IMHO). Більшість мого коду працює з HTTP. І я думаю, що мій описаний випадок використання не обійдеться без цього.

— Норберт Хартл

Ви завжди можете надіслати тіло назад - надішліть 200 із відповіддю JSON або все, що завгодно, щоб визначити, які з них були успішними.

— Кайлар

Так, я знаю. Але якщо ви повернете тіло, вам потрібно його розібрати. І в цей момент ви вводите другий рівень логіки обробки додатків. Це підвищує складність, і для цього вам потрібна вагома причина.

— Норберт Хартл

65

У мене була та сама проблема, і я закінчив використовувати два різні рішення:

Код повернення HTTP 202: Accepted, що вказує на те, що з запитом було нормально, але немає гарантії, що насправді все пройшло як слід.
Поверніть нормальну характеристику 200у відповіді, але додайте список того, що не вимкнулось в тілі відповідей.

Другий, як правило, працює найкраще, але перший чудовий, якщо ти лінивий або використовуєш чергу для обробки.

— Арне
джерело

5

Хіба 202 більше не посилається на щось на зразок черги?

— Сінестетик

6

Так, @Sinaesthetic. З останньої специфікації HTTP 1.1 "(...) запит прийнято до обробки, але обробка не завершена". Отже, для часткового успіху 202 не підходить.

— Хуерсіо

-4

А як щодо використання 206 Часткового вмісту. Я знаю, що 206 більше стосується діапазонів, але що робити, якщо це може означати частково успішний запит?

— Юсуф
джерело

MDN заявляє наступним чином: "Код відповіді про стан успішності часткового вмісту HTTP 206 вказує на те, що запит вдався і тіло містить запитувані діапазони даних, як описано в заголовку діапазону запиту." Наскільки я розумію, 206 Частковий вміст призначений виключно для запитів із діапазоном вмісту.

— sbbs

-14

Протокол передачі HyperText стосується передачі речей. У ньому немає кодів помилок, щоб вирішувати помилки на рівні програми.

Повернення 200 - це правильна справа. Щодо HTTP, запит отримано належним чином, обробляється належним чином, і ви надсилаєте відповідь назад. Отже, на рівні HTTP все гаразд. Будь-які помилки або попередження, пов’язані з додатком, який працює поверх http, повинен знаходитись у відповіді. Це також запобіжить деякі неприємні проблеми, з якими ви можете зіткнутися з проксі-серверами, які можуть не обробляти певні відповіді так, як ви очікуєте.

— AVee
джерело

18

HTTP - протокол рівня додатків. Ви не можете просто розмістити його на транспортному та додатковому рівні. Якщо ви думаєте про OSI, то HTTP знаходиться на шарах 5-7. HTTP дещо відрізняється. Більшість заголовків і зворотних кодів дійсно специфічні для програми. Коди просто залежать від інформації, наданої у сукупностях протоколу HTTP, а не від речей спеціального формату додатків. Щодо 200, я б сказав, що ваше визначення є абсолютно неправильним, якщо воно застосовується до дієслів, які не є POST. Але POST трохи змінює гру, і в цьому контексті ваше припущення "правильно поводиться" теж не впевнене

— Norbert Hartl

Власне кажучи, OSI вважає HTTP протоколом рівня додатків, і коли говорити з "звичайним" веб-сервером, це правда. Але у вашому випадку ви запускаєте власний протокол поверх HTTP, як це робиться в наші дні. У такому типі використання HTTP просто забезпечує транспорт. (Ваша програма надсилає повідомлення користувачам, не передаючи гіпертекст ...)

— AVee

2

Просто, щоб було зрозуміло. HTTP способом REST орієнтований на ресурси. У цьому контексті 200 означає ідентичність (вказаний вами ресурс) замість 3xx, який вказує у напрямку ідентичності. Використання POST перетворює URI ресурсу в URI обробки, і там потрібні коди помилок, щоб впоратися з цим. Контекст трохи зміщується, і визначення речей стає трохи розмитим або принаймні важко зрозумілим

— Норберт Хартл

1

Зміна контексту також означає, що немає відповідних кодів помилок, оскільки протокол ніколи не був розроблений з урахуванням цього контексту ;-) Я також думаю, що вам слід бути обережними з використанням кодів помилок, оскільки проксі-сервери, як правило, працюють із ними, замінюючи вашу відповідь користувацька сторінка помилок, це може бути справжнім PITA.

— AVee

1

У будь-якому випадку, дякую за відповідь на моє запитання. Щойно я виявив, що stackoverflow - це поганий клієнт чату :)

— Норберт Хартл