Чи слід використовувати коди статусу HTTP для опису подій на рівні програми

Кілька серверів, з якими я мав справу, повернуть HTTP 200 для запитів, які клієнт повинен вважати помилкою, з тілом як "успіх: помилка".

Мені це не здається належним впровадженням HTTP-кодів, особливо у випадках невдалої аутентифікації. Я прочитав коди помилок HTTP досить коротко підсумовані, оскільки "4xx" вказує на те, що запит не слід робити знову до зміни, тоді як "5xx" вказує на те, що запит може бути неправдивим і може бути повторним, але був невдалим. У цьому випадку 200: вхід не вдалося, або 200: не вдалося знайти цей файл, або 200: відсутній параметр x, безумовно, здається неправильним.

З іншого боку, я міг бачити аргумент, що "4xx" повинен вказувати лише на структурну проблему із запитом. Тож належним чином повернути 200: поганий користувач / пароль, а не 401 несанкціонований, оскільки клієнту дозволяється робити запит, але це трапляється неправильно. Цей аргумент можна узагальнити так, якби сервер зміг обробити запит і визначитись, код відповіді повинен бути 200, і клієнт повинен перевірити орган для отримання додаткової інформації.

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

Цікаве запитання.

В основному ми можемо звести це до правильного способу класифікації речей, аналогічних шарам OSI. HTTP зазвичай визначається як протокол рівня програми, а HTTP справді є загальним протоколом клієнт / сервер.

Однак на практиці сервер майже завжди є ретрансляційним пристроєм, а клієнт - веб-браузером, відповідальним за інтерпретацію та передачу вмісту: сервер просто передає речі до довільної програми, а додатки надсилають назад довільні сценарії, які браузер відповідає за виконання. Сама взаємодія HTTP - форми запиту / відповіді, коди статусу тощо - це здебільшого справа про те, як запитувати, обслуговувати та видавати довільний вміст максимально ефективно, не заважаючи. Багато кодів статусу та заголовків дійсно створені для цих цілей.

Проблема з спробою підсилити протокол HTTP для обробки потоків, що стосуються додатків, полягає в тому, що вам залишається один з двох варіантів: 1) Ви повинні зробити свою логіку запиту / відповіді підмножиною правил HTTP; або 2) Ви повинні повторно використовувати певні правила, і тоді відокремлення проблем має тенденцію до нечітких. Спочатку це може виглядати красиво і чисто, але я думаю, що це одне з тих дизайнерських рішень, про які ви, в кінцевому рахунку, шкодуєте, коли ваш проект розвивається.

Тому я б сказав, що краще бути чітким щодо розділення протоколів. Нехай сервер HTTP і веб-браузер роблять свою справу, і програма нехай робить свою справу. Додаток повинен вміти робити запити, і йому потрібні відповіді - і його логіка щодо того, як запитувати, як інтерпретувати відповіді, може бути більш (або менш) складною, ніж перспектива HTTP.

Інша перевага цього підходу, яку варто зазначити, полягає в тому, що програми, як правило, не повинні залежати від базового транспортного протоколу (з логічної точки зору). Сам HTTP змінився в минулому, і тепер ми починаємо HTTP 2, слідуючи SPDY. Якщо ви вважаєте, що ваш додаток не є додатком додатка для HTTP-функцій, ви можете застрягнути там, коли перейдуть нові інфраструктури.

Це питання на основі думки, але в будь-якому випадку.

Те, як я це бачу, 200 може подати "м'які помилки". Що стосується створення API, я намагаюся розрізняти ці "жорсткі помилки".

"М'які помилки" подаватимуться з кодом статусу 200, але містять опис помилки та статус успішності false. "М'які помилки" трапляться лише тоді, коли результат буде "як очікувалося", але не буде успіхом у найсуворішому сенсі.

Важливо зазначити, що "м'які помилки" - це більше натяк на реалізатора. Для цього важливо також надати додаткову інформацію про помилку, таку як людське повідомлення про помилку та / або якийсь код, який можна використовувати для надання кінцевому користувачеві зворотного зв'язку. Ці помилки надають реалізатору (і кінцевому користувачеві) більше інформації про те, що сталося на стороні сервера .

Наприклад, у вас є API з функцією пошуку, але під час пошуку результати не даються. Це не помилково, але це також не «успіх», не в суворому розумінні визначення.

Приклад відформатований як JSON:

{
    "meta" {
        "success": false,
        "message": "Search yielded no results",
        "code": "NORESULTS"
    }
    "data": []
}

З іншого боку, "жорсткі помилки" подаватимуться з кодом статусу, який рекомендовано для помилки. Користувач не ввійшов у систему? - 403 / 401. Неправильний вхід? - 400. Помилка сервера? - 50X. І так далі.

Знову ж таки, це трохи ґрунтується на думці. Деякі люди хочуть ставитися до всіх помилок однаково, "важко помиляючись" у всьому. Немає результатів пошуку? Це 404! З іншого боку монети немає результатів пошуку? - Це як очікувалося, помилок немає.

Ще одним важливим фактором, який слід врахувати, є, наприклад, ваша архітектура; якщо ви взаємодієте зі своїм API за допомогою XHR запитів JavaScript та jQuery або AngularJS. Ці "жорсткі помилки" доведеться обробляти окремим зворотним викликом, тоді як "м'які помилки" можна обробляти за допомогою "успіху" -викликання. Нічого не порушуючи, результат все одно «як очікувався». Потім клієнтський код може переглянути стан успіху та код (або повідомлення). І роздрукуйте це для кінцевого споживача.

Є два аспекти API: намагання впровадити API та намагання всіх клієнтів правильно використовувати API.

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

Створюючи API, слід переглянути, що клієнту найпростіше обробити. Якщо клієнт надсилає добре сформований запит, і ви можете робити те, що просить вас зробити, тоді вам слід дати відповідь у діапазоні 200 (є деякі випадки, коли число, яке не є 200, у цьому діапазоні є відповідним).

Якщо клієнт просить "дати мені всі записи, як ...", а там нуль, то 200 з успіхом і масив нульових записів цілком підходить. Випадки, про які ви згадуєте:

"Не вдалося ввійти" зазвичай має бути 401. "Не вдалося знайти файл" має бути 404. "Відсутній параметр x" повинен бути приблизно 500 (насправді 400, якщо сервер визначить, що запит поганий, і 500 якщо сервер повністю збентежений моїм запитом і не має уявлення, що відбувається). Повертати 200 у цих випадках безглуздо. Це просто означає, що як автор клієнта, я не можу просто подивитися на код статусу, я також повинен вивчити відповідь. Я не можу просто сказати "статус 200, чудово, ось дані".

Особливо "параметр відсутній" - це не те, з чим я коли-небудь впорався б . Це означає, що мій запит невірний. Якщо мій запит невірний, у мене немає резервної копії, щоб виправити цей неправильний запит - для початку я надішлю правильний запит. Тепер я змушений це впоратися. Я отримую 200 і повинен перевірити, чи немає відповіді "параметр відсутній". Це жахливо.

Зрештою, існує десяток-два коди статусу для вирішення багатьох різних ситуацій, і ви повинні їх використовувати.