Мне интересно, правильно ли возвращать HTTP 200 OK, когда ошибка на стороне сервера произошла с некоторой ошибкой внутри тела ответа.
Пример:
http GETHTTP 200 OK код состояния с ошибкой внутри ответа (например, {"status":"some error occured"}Является ли правильное поведение или нет? Разве мы не должны менять код состояния?
Нет, это очень неверно.
HTTP - протокол приложения. 200 подразумевает, что ответ содержит полезную нагрузку, которая представляет статус запрашиваемого ресурса. Сообщение об ошибке обычно не является представлением этого ресурса.
Если во время обработки GET что-то пойдет не так, правый код состояния - 4xx ( "вы испортились" ) или 5xx ( "Я испортил" ).
Коды состояния HTTP говорят что-то о протоколе HTTP. HTTP 200 означает, что передача в порядке на уровне HTTP (т.е. запрос был технически корректным, и сервер смог правильно ответить). См. эту страницу вики для списка всех кодов и их значения.
HTTP 200 не имеет ничего общего с успехом или неудачей вашего "бизнес-кода". В вашем примере HTTP 200 является приемлемым статусом, указывающим, что ваше сообщение об ошибке "бизнес-код" было успешно передано при условии, что никакие технические проблемы не позволили правильной работе бизнес-логики.
В качестве альтернативы вы можете позволить вашему серверу ответить HTTP 5xx, если на сервере возникли технические или неустранимые проблемы. Или HTTP 4xx, если у входящего запроса были проблемы (например, неправильные параметры, неожиданный метод HTTP...). Все это указывает на технические ошибки, тогда как HTTP 200 указывает НЕТ технические ошибки, но не дает никаких гарантий относительно ошибок бизнес-логики.
Подводя итог: YES, необходимо отправить сообщения об ошибках (для нетехнических проблем) в вашем ответе HTTP вместе с HTTP-статусом 200. Будет ли это применимо к вашему делу, зависит от вас. Если, например, клиент запрашивает файл, которого нет, это будет больше похоже на 404. Если на сервере существует некорректная конфигурация, которая может быть 500. Если клиент запросит место на самолете, который будет забронирован, это будет 200, и ваша "реализация" будет определять, как распознавать/обрабатывать это (например, блок JSON с { "booking","failed" })
Даже если я хочу вернуть ошибку бизнес-логики в качестве HTTP-кода, нет такого допустимый код ошибки HTTP для этих ошибок, а не использование HTTP 200, поскольку он будет искажать фактическую ошибку.
Таким образом, HTTP 200 будет хорош для ошибок бизнес-логики. Но все ошибки, которые покрываются кодами ошибок HTTP, должны их использовать.
В основном HTTP 200 означает, что сервер правильно обрабатывает запрос пользователя (в случае отсутствия мест на плоскости это неважно, потому что запрос пользователя был правильно обработан, он может даже вернуть только несколько мест, доступных на самолете, поэтому вообще не будет ошибок бизнес-логики или что бизнес-логика может быть на стороне клиента. Ошибка бизнес-логики - абстрактное значение, но ошибка HTTP более определенна).
Для пояснения следует использовать коды ошибок HTTP, если они соответствуют протоколу, и не использовать коды состояния HTTP для отправки бизнес-логики ошибок.
Ошибки, такие как недостаточный баланс, отсутствие доступных кабинетов, неправильный пользователь/пароль соответствуют статусу HTTP 200 с обработкой ошибок конкретного приложения в теле ответа.
Смотрите этот ответ по разработке программного обеспечения:
Я бы сказал, что лучше четко указывать разделение протоколов. Пусть HTTP-сервер и веб-браузер делают свое дело, а приложение делает свое дело. Приложение должно иметь возможность делать запросы, и ему нужны ответы - и его логика относительно того, как запрашивать, как интерпретировать ответы, может быть более (или менее) сложной, чем перспектива HTTP.
HTTP - протокол, обрабатывающий передачу данных через Интернет.
Если эта передача прерывается по какой-либо причине, коды ошибок HTTP сообщают вам, почему она не может быть отправлена вам.
Передаваемые данные не обрабатываются кодами ошибок HTTP. Только способ передачи.
HTTP не может сказать: "Хорошо, этот ответ - болтовня, но вот он". это просто говорит 200 OK.
Т.е. я выполнил свою задачу, чтобы доставить ее вам, остальное зависит от вас.
Я знаю, что на этот вопрос уже дан ответ, но я выразил это словами, которые могу понять. извините за любое повторение.
Я думаю, что люди придают слишком большое значение логике приложения по сравнению с вопросом протокола. Важно то, что ответ должен иметь смысл. Что если у вас есть API, который обслуживает динамический ресурс, и делается запрос для X, который получен из шаблона Y с данными Z, а либо Y, либо Z в настоящее время недоступны? Это ошибка бизнес-логики или техническая ошибка? Правильный ответ: "кого это волнует?"
Ваш API и ваши ответы должны быть понятными и последовательными. Он должен соответствовать какой-то спецификации, и эта спецификация должна определять, каков действительный ответ. То, что соответствует действительному ответу, должно дать код 200. Что-то, что не соответствует действительному ответу, должно давать код 4xx или 5xx, указывающий, почему действительный ответ не может быть сгенерирован.
Если ваше определение спецификации действительного ответа разрешает { "error": "invalid ID" }, то это успешный ответ. Если ваша спецификация не предусматривает такое размещение, было бы плохим решением вернуть этот ответ с кодом 200.
Я бы провел аналогию с вызовом функции parseFoo. Что происходит, когда вы звоните parseFoo("invalid data")? Возвращает ли он результат ошибки (возможно, null)? Или это исключение? Многие займут почти религиозную позицию относительно того, является ли тот или иной подход правильным, но в конечном итоге это соответствует спецификации API.
"Элемент кода состояния представляет собой трехзначный целочисленный код, дающий результат попытки понять и удовлетворить запрос"
Очевидно, что существует различие во мнениях относительно того, является ли "успешное возвращение ошибки" HTTP-успехом или ошибкой. Я вижу, как разные люди по-разному интерпретируют одни и те же спецификации. Так что выбирайте сторону, конечно, но также принимайте, что в любом случае весь мир не согласится с вами. Меня? Я нахожусь где-то посередине, но я предлагаю некоторые общие соображения.
500 Internal Server Error. Кажется, это OP-ситуация. Приложение не должно возвращать 200 для непредвиденных ошибок,, но также см. пункт 3.В ситуации OP, похоже, у вас есть де-факто стандарт, согласно которому необработанные исключения дают 200 с отличимым телом ответа. Это не идеал, но если он не ломает вещи и не вызывает проблем, у вас, вероятно, есть более важные проблемы.