Должен ли я использовать коды состояния HTTP для описания событий уровня приложения

Несколько серверов, с которыми я имел дело, будут возвращать HTTP 200 для запросов, которые клиент должен рассматривать как сбой, с чем-то вроде «success: false» в теле.

Это не похоже на правильную реализацию 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. Ошибка сервера? - 50Х. И так далее.

Опять же, это немного основано на мнении. Некоторые люди хотят одинаково относиться ко всем ошибкам, ко всем - к "жесткой ошибке". Нет Результатов Поиска? Это 404! На другой стороне медали нет результатов поиска? - Это, как и ожидалось, без ошибок.

Другим важным фактором, который следует принимать во внимание, является, например, ваша архитектура; если вы взаимодействуете с вашим API, используя JavaScript XHR-запросы и jQuery или AngularJS. Эти "серьезные ошибки" должны обрабатываться отдельным обратным вызовом, тогда как "мягкие ошибки" могут обрабатываться с помощью "success" -callback. Ничего не нарушая, результат все еще "как и ожидалось". Код на стороне клиента может затем посмотреть на статус успеха и код (или сообщение). И распечатайте это для конечного пользователя.

Существует два аспекта API: усилия по реализации API и усилия всех клиентов правильно использовать API.

Как автор клиента, я знаю, что когда я отправляю запрос на веб-сервер, я могу получить либо ошибку (никогда не общалась с сервером должным образом), либо ответ с кодом состояния. Я должен справиться с ошибками. Я должен справиться с хорошим ответом. Я должен справиться с ожидаемыми, задокументированными, «плохими» ответами. Я должен справиться с тем, что еще возвращается.

Разрабатывая API, вы должны посмотреть, что проще всего обрабатывать клиенту. Если клиент отправляет правильно сформированный запрос, и вы можете делать то, что запрашивает ваш запрос, вы должны дать ответ в диапазоне 200 (в некоторых случаях подходит число, отличное от 200 в этом диапазоне).

Если клиент спрашивает «дать мне все записи, как ...», и их число равно нулю, тогда 200 с успехом и массив с нулевыми записями полностью уместны. Случаи, которые вы упоминаете:

«Ошибка входа в систему» ​​обычно должна быть 401. «Файл не найден» должен быть 404. «Отсутствующий параметр x» должен быть около 500 (на самом деле, 400, если сервер обнаруживает, что запрос плохой, и 500 если сервер полностью сбит с толку моим запросом и не знает, что происходит). Возвращать 200 в этих случаях бессмысленно. Это просто означает, что, как автор клиента, я не могу просто посмотреть на код состояния, я также должен изучить ответ. Я не могу просто сказать «статус 200, отлично, вот данные».

Особенно «отсутствие параметров» - это не то, с чем я бы когда-либо справился . Это означает, что мой запрос неверен. Если мой запрос неверный, у меня нет запасного варианта, чтобы исправить этот неправильный запрос - я бы отправил правильный запрос для начала. Теперь я вынужден справиться с этим. Я получаю 200 и должен проверить, есть ли ответ «отсутствует параметр». Это ужасно.

В конце концов, есть дюжина или два кода состояния для обработки множества различных ситуаций, и вы должны их использовать.