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

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

Это не похоже на правильную реализацию HTTP-кодов для меня, особенно в случае неудачной проверки подлинности. Я прочитал коды ошибок HTTP, довольно сжато суммированные, так как «4xx» указывает, что запрос не должен делаться снова до тех пор, пока не будет изменен, а «5xx» указывает, что запрос может быть или недействительным и может быть повторен, но не был выполнен. В этом случае 200: login failed или 200: не удалось найти этот файл, или 200: отсутствует параметр x, определенно кажется неправильным.

С другой стороны, я мог видеть, что аргумент заключается в том, что «4xx» должен указывать только структурную проблему с запросом. Так что правильно возвращать 200: плохой пользователь /пароль, а не 401, неавторизованный, потому что клиенту разрешено делать запрос, но это бывает некорректно. Этот аргумент можно суммировать так, как если бы сервер смог обработать запрос и сделать определение вообще, код ответа должен быть 200, и клиент должен проверить тело для получения дополнительной информации.

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

44 голоса | спросил Kagan Mattson 16 WedEurope/Moscow2015-12-16T21:11:22+03:00Europe/Moscow12bEurope/MoscowWed, 16 Dec 2015 21:11:22 +0300 2015, 21:11:22

3 ответа


25

Интересный вопрос.

В принципе, мы можем уменьшить это до нужного пути, чтобы классифицировать вещи в терминах, аналогичных уровням OSI. HTTP обычно определяется как протокол уровня приложения, а HTTP действительно является общим протоколом Client /Server.

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

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

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

Другим преимуществом такого подхода, о котором стоит упомянуть, является то, что приложения, вообще говоря, не должны зависеть от базового транспортного протокола (с логической точки зрения). Сам HTTP изменился в прошлом, и теперь у нас есть HTTP 2, после SPDY. Если вы рассматриваете приложение как не более, чем плагин функциональных возможностей HTTP, вы можете застрять там, когда начнут работать новые инфраструктуры.

ответил Yam Marcovic 17 ThuEurope/Moscow2015-12-17T12:31:17+03:00Europe/Moscow12bEurope/MoscowThu, 17 Dec 2015 12:31:17 +0300 2015, 12:31:17
19

Этот вопрос немного основан на мнениях, но в любом случае.

Как я вижу, 200 может служить «мягкими ошибками». Когда дело доходит до построения API, я стараюсь различать эти и «жесткие ошибки».

«Мягкие ошибки» будет обслуживаться с кодом состояния 200, но будет содержать описание ошибки и статус успеха false. «Мягкие ошибки» будут возникать только тогда, когда результат «как ожидалось», но не будет успешным в самом строгом смысле.

Важно отметить, что «мягкие ошибки» - это больше hint для исполнителя. Поэтому важно также предоставить дополнительную информацию об ошибке, например, о человекочитаемом сообщении об ошибке и /или о каком-то коде, который может использоваться для предоставления конечным пользователям обратной связи. Эти ошибки предоставляют разработчику (и конечному пользователю) больше информации о том, что произошло на стороне сервера .

Например, у вас есть API с функцией поиска, но во время поиска результаты не получаются. Это не ошибочно, но это не «успех», а не в строгом смысле этого определения.

Пример форматирования как JSON:

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

«Жесткие ошибки» , с другой стороны, будет обслуживаться с кодом состояния, который рекомендуется для ошибки. Пользователь не вошел? - 403 /401. Неправильный ввод? 400. Ошибка сервера? 50X. И так далее.

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

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

ответил die maus 16 WedEurope/Moscow2015-12-16T22:18:47+03:00Europe/Moscow12bEurope/MoscowWed, 16 Dec 2015 22:18:47 +0300 2015, 22:18:47
13

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

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

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

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

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

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

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

ответил gnasher729 17 ThuEurope/Moscow2015-12-17T00:45:46+03:00Europe/Moscow12bEurope/MoscowThu, 17 Dec 2015 00:45:46 +0300 2015, 00:45:46

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132