Я думаю, что люди придают слишком большое значение логике приложения, а не протоколу. Важно то, что ответ должен иметь смысл. Что делать, если у вас есть API, обслуживающий динамический ресурс, и делается запрос для X, который получен из шаблона Y с данными Z, а Y или Z в настоящее время недоступны? Это ошибка бизнес-логики или техническая ошибка? Правильный ответ: "кого это волнует?"
Ваш API и ваши ответы должны быть понятными и последовательными. Он должен соответствовать какой-то спецификации, и эта спецификация должна определять, что такое действительный ответ. Что-то, что соответствует действительному ответу, должно дать код 200. Что-то, что не соответствует действительному ответу, должно давать код 4xx или 5xx, указывающий на то, почему не может быть сгенерирован действительный ответ.
Если определение допустимого ответа в вашей спецификации допускает { "error": "invalid ID" }
, то это успешный ответ. Если ваша спецификация не делает этого приспособления, было бы плохим решением возвращать этот ответ с кодом 200.
Я бы провел аналогию с вызовом функции parseFoo
. Что происходит, когда вы звоните parseFoo("invalid data")
? Возвращает ли он результат ошибки (возможно, нулевой)? Или возникает исключение? Многие займут почти религиозную позицию относительно правильности того или иного подхода, но в конечном итоге это зависит от спецификации API.
«Элемент status-code - это трехзначный целочисленный код, дающий результат попытки понять и удовлетворить запрос»
Очевидно, есть разногласия относительно того, является ли «успешное возвращение ошибки» успехом или ошибкой HTTP. Я вижу, как разные люди интерпретируют одни и те же характеристики по-разному. Так что выберите сторону, конечно, но также примите тот факт, что в любом случае весь мир не согласится с вами. Мне? Я нахожусь где-то посередине, но предлагаю некоторые соображения здравого смысла.
- Если ваш серверный код обнаруживает неожиданное исключение при отправке запроса, это похоже на само определение
500 Internal Server Error
. Это похоже на ситуацию OP. Приложение не должно возвращать 200
в случае непредвиденных ошибок, но также см. Пункт 3.
- Если ваш серверный код должен уметь корректно обрабатывать данный недопустимый ввод, и он не представляет собой «исключительного» состояния ошибки, ваша спецификация должна учитывать ответы HTTP 200, которые предоставляют значимую диагностическую информацию.
- Прежде всего: Имейте спецификацию. Сделайте это последовательным. Придерживайтесь этого.
В ситуации OP похоже, что у вас есть стандарт де-факто, согласно которому необработанные исключения дают 200 с отличимым телом ответа. Это не идеально, но если он не ломает вещи и не вызывает активных проблем, у вас, вероятно, есть более серьезные и важные проблемы, которые нужно решить.
person
snarf
schedule
08.08.2019