Возврат http 200 OK с ошибкой в ​​теле ответа

Коды состояния HTTP кое-что говорят о протоколе HTTP. HTTP 200 означает, что передача в порядке на уровне HTTP (т.е. запрос был технически в порядке и сервер смог правильно ответить). См. эту страницу вики для получения списка всех кодов и их значения.

HTTP 200 не имеет ничего общего с успехом или неудачей вашего бизнес-кода. В вашем примере HTTP 200 является приемлемым статусом, чтобы указать, что сообщение об ошибке вашего бизнес-кода было успешно передано, при условии, что никакие технические проблемы не помешали правильной работе бизнес-логики.

В качестве альтернативы вы можете позволить своему серверу ответить HTTP 5xx, если на сервере возникнут технические или неустранимые проблемы. Или HTTP 4xx, если во входящем запросе были проблемы (например, неправильные параметры, неожиданный метод HTTP ...). Опять же, все это указывает на технические ошибки, тогда как HTTP 200 указывает на НЕТ технических ошибок, но не дает никаких гарантий относительно ошибок бизнес-логики.

Подводя итог: ДА, можно отправлять сообщения об ошибках (для нетехнических проблем) в вашем 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.

Я думаю, что подобные проблемы решаются, если мы думаем о реальной жизни.

Плохая практика:

Пример 1:

Darling everything is FINE/OK (HTTP CODE 200) - (Success):
{
  ...but I don't want us to be together anymore!!!... (Error)
  // Then everything isn't OK???
}

Пример 2:

You are the best employee (HTTP CODE 200) - (Success):
{
  ...But we cannot continue your contract!!!... (Error)
  // Then everything isn't OK???
}

Передовой опыт:

 Darling I don't feel good (HTTP CODE 400) - (Error):
{
  ...I no longer feel anything for you, I think the best thing is to separate... (Error)
  // In this case, you are alerting me from the beginning that something is wrong ...
}

Это только мое личное мнение, каждый может реализовать его так, как ему удобнее или нужно.

Примечание. Идея этого объяснения была получена от хорошего друга @diosney

Я думаю, что люди придают слишком большое значение логике приложения, а не протоколу. Важно то, что ответ должен иметь смысл. Что делать, если у вас есть API, обслуживающий динамический ресурс, и делается запрос для X, который получен из шаблона Y с данными Z, а Y или Z в настоящее время недоступны? Это ошибка бизнес-логики или техническая ошибка? Правильный ответ: "кого это волнует?"

Ваш API и ваши ответы должны быть понятными и последовательными. Он должен соответствовать какой-то спецификации, и эта спецификация должна определять, что такое действительный ответ. Что-то, что соответствует действительному ответу, должно дать код 200. Что-то, что не соответствует действительному ответу, должно давать код 4xx или 5xx, указывающий на то, почему не может быть сгенерирован действительный ответ.

Если определение допустимого ответа в вашей спецификации допускает { "error": "invalid ID" }, то это успешный ответ. Если ваша спецификация не делает этого приспособления, было бы плохим решением возвращать этот ответ с кодом 200.

Я бы провел аналогию с вызовом функции parseFoo. Что происходит, когда вы звоните parseFoo("invalid data")? Возвращает ли он результат ошибки (возможно, нулевой)? Или возникает исключение? Многие займут почти религиозную позицию относительно правильности того или иного подхода, но в конечном итоге это зависит от спецификации API.

«Элемент status-code - это трехзначный целочисленный код, дающий результат попытки понять и удовлетворить запрос»

Очевидно, есть разногласия относительно того, является ли «успешное возвращение ошибки» успехом или ошибкой HTTP. Я вижу, как разные люди интерпретируют одни и те же характеристики по-разному. Так что выберите сторону, конечно, но также примите тот факт, что в любом случае весь мир не согласится с вами. Мне? Я нахожусь где-то посередине, но предлагаю некоторые соображения здравого смысла.

1. Если ваш серверный код обнаруживает неожиданное исключение при отправке запроса, это похоже на само определение 500 Internal Server Error. Это похоже на ситуацию OP. Приложение не должно возвращать 200 в случае непредвиденных ошибок, но также см. Пункт 3.
2. Если ваш серверный код должен уметь корректно обрабатывать данный недопустимый ввод, и он не представляет собой «исключительного» состояния ошибки, ваша спецификация должна учитывать ответы HTTP 200, которые предоставляют значимую диагностическую информацию.
3. Прежде всего: Имейте спецификацию. Сделайте это последовательным. Придерживайтесь этого.

В ситуации OP похоже, что у вас есть стандарт де-факто, согласно которому необработанные исключения дают 200 с отличимым телом ответа. Это не идеально, но если он не ломает вещи и не вызывает активных проблем, у вас, вероятно, есть более серьезные и важные проблемы, которые нужно решить.

HTTP - это протокол, обрабатывающий передачу данных через Интернет.

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

Передаваемые данные не обрабатываются кодами ошибок HTTP. Только способ передачи.

HTTP не может сказать: «Хорошо, это чепуха, но вот он». он просто говорит 200 OK.

То есть: я выполнил свою работу по доставке его вам, остальное зависит от вас.

Я знаю, что на это уже был дан ответ, но я изложил это словами, которые я могу понять. извините за повторение.