Я б сказав, жоден із насправді не підходить. Як було сказано - наприклад, від @anneb, я також вважаю, що частина проблем виникає в результаті використання коду відповіді HTTP для транспортування статусу, що стосується послуги RESTful. Все, що може сказати службі REST про власну обробку, слід транспортувати за допомогою спеціальних кодів REST.
1
Я б стверджував, що якщо сервер HTTP знайде будь-яку службу, яка готова відповісти на запит, на який він був надісланий, він не повинен відповідати HTTP 404 - врешті-решт, щось було знайдено сервером - якщо це прямо не сказано сервіс, який обробляє запит.
Давайте на хвилину припустимо наступний URL: http://example.com/service/return/test.
- Випадок A полягає в тому, що сервер "просто шукає файл у файловій системі". Якщо його немає,
404правильно. Те саме відбувається, якщо він просить якусь службу доставити саме цей файл, і ця служба каже йому, що нічого з цього імені не існує.
- У випадку B сервер не працює з "реальними" файлами, але насправді запит обробляється якоюсь іншою службою - наприклад, якоюсь системою шаблонів. Тут сервер не може пред'являти жодних претензій щодо існування ресурсу, оскільки він нічого про нього не знає (якщо тільки не повідомила служба, що обробляє його).
Без будь-якої відповіді служби, яка явно вимагає іншої поведінки, сервер HTTP може сказати лише 3 речі:
503 якщо служба, яка повинна обробляти запит, не працює або не відповідає;200 в іншому випадку, оскільки сервер HTTP може фактично задовольнити запит - незалежно від того, що служба скаже пізніше;400або 404вказувати на відсутність такої послуги (на відміну від "існує, але офлайн") і нічого іншого не знайдено.
2
Щоб повернутися до питання: я думаю, що найчистішим підходом було б не використовувати HTTP будь-який код відповіді, окрім сказаного раніше. Якщо служба присутня та відповідає, код HTTP повинен бути 200. Відповідь має містити статус, який служба повертає в окремому заголовку - тут служба може сказати
REST:EMPTYнаприклад, якщо його просили шукати що-небудь. і це дослідження повернулося порожнім;REST:NOT FOUNDякщо його просили спеціально для чого-небудь. "Ідентифікатор, подібний до ідентифікації" - це ім'я файлу або ресурсу за ідентифікаційним номером або записом № 24 тощо. - і конкретний ресурс не знайдений (як правило, один конкретний ресурс запитувався і не був знайдений);REST:INVALID якщо будь-яка частина запиту, який він надіслала, служба не визнає.
(зауважте, що я заздалегідь встановив їх за допомогою "REST:", щоб позначити той факт, що, хоча вони можуть мати ті ж значення або формулювання, що і коди відповідей HTTP, вони є що-небудь зовсім інше)
3
Повернемося до вищезгаданої URL-адреси та перевіримо випадок B, коли служба вказує HTTP-серверу, що він сам не обробляє цей запит, а передає його на SERVICE. HTTP обслуговує лише те, що йому передано SERVICE, він нічого не знає про return/testчастину, якою обробляється SERVICE. Якщо ця послуга запущена, HTTP повинен повернутися, 200оскільки він дійсно знайшов щось для обробки запиту.
Статус, який повертається SERVICE(і який, як було сказано вище, хотілося б бачити в окремому заголовку), залежить від того, яку дію очікують насправді:
- якщо
return/testзапитує конкретний ресурс: якщо він існує, поверніть його зі статусом REST:FOUND; якщо цього ресурсу не існує, поверніться REST:NOT FOUND; це може бути продовжено до повернення, REST:GONEякщо ми знаємо, що воно колись існувало і не повернеться, і REST:MOVEDякщо ми знаємо, що воно пішло в голлівуд
- якщо
return/testвважається пошуковою чи фільтрованою операцією: якщо набір результатів порожній, поверніть порожній набір у запитуваному типі та статусі REST:EMPTY; набір результатів у запитуваному типі та статусіREST:SUCCESS
- якщо
return/testце не операція, яку розпізнає SERVICE: поверніть, REST:ERRORякщо вона абсолютно неправильна (наприклад, помилка друку retrun/test), або REST:NOT IMPLEMENTEDякщо вона планується на потім.
4
Ця відмінність набагато чистіше, ніж змішування двох різних речей. Це також полегшить налагодження та обробку лише трохи складнішою, якщо вона взагалі є.
- Якщо HTTP 404 повернуто, сервер мені каже: "Я не маю поняття, про що ви говорите". Незважаючи на те, що частина REST мого запиту може бути точно в порядку, я шукаю par'Mach у всіх неправильних місцях.
- З іншого боку, HTTP 200 та REST: ERR повідомляє мені, що я отримав послугу, але щось зробив не так у своєму запиті до служби.
- З HTTP 200 та REST: EMPTY я знаю, що я нічого поганого не зробив - правильний сервер, сервер знайшов службу, правильний запит до сервісу - але результат пошуку порожній.
Підсумок
Проблема та обговорення виникає з того, що коди відповідей HTTP використовуються для позначення стану служби, результати якої обслуговуються HTTP, або для позначення sth. це не входить до сфери дії самого HTTP-сервера. Через цю невідповідність на питання не можна відповісти, і всі думки піддаються великій дискусії.
Стан запиту, обробленого службою, а не HTTP-сервером, дійсно НЕ повинен (RFC 6919) надаватися кодом відповіді HTTP. Код HTTP ПОТРІБНО (RFC 2119) містить лише інформацію, яку сервер HTTP може надати з власної сфери: а саме, чи було виявлено, що служба обробляє запит чи ні.
Натомість слід використовувати інший спосіб повідомляти споживача про стан запиту до служби, яка фактично обробляє запит. Моя пропозиція - зробити це через певний заголовок. В ідеалі, як назва заголовка, так і його зміст відповідають стандарту, який спрощує роботу споживачів з тезами.
