В чем разница между неудачей и ошибкой в спецификации JSend?
Согласно https://labs.omniti.com/labs/jsend,
- Ошибка: когда вызов API отклонен из-за недопустимых данных или условий вызова.
- Ошибка: при сбое вызова API из-за ошибки на сервере
Можно ли это интерпретировать как ошибки 4xx (например, 404) всегда должны возвращать Fail, но ошибки 5xx всегда соответствуют Error?
Ответы 1
Это отличный вопрос, и я отвечу на него конкретным примером из собственного опыта. В API одного из моих проектов я разрешаю загрузку электронной таблицы Excel, которая обрабатывается, а полученный JSON сохраняется на сервере.
Если при сохранении данных на диск возникает ошибка, я отвечу сообщением об ошибке JSend вместе с соответствующим сообщением об ошибке, поскольку данные должен удалось сохранить.
Если, с другой стороны, данные в одной из строк недействительны (возможно, неправильный тип данных или ошибка диапазона), то я знаю точную строку (или строки) электронной таблицы, которые были неправильными. В этом случае подходит ответ «сбой», поскольку свойство data ответа JSend будет содержать список всех строк (номер строки и сообщение об ошибке) для каждой необработанной строки.
В случае ответа «ошибка» у меня не было бы такой возможности, так как я был бы ограничен одним свойством message. Но с ответом «сбой» у меня есть свойство data, где я могу ответить подробным списком проблем.
Таким образом, хотя ошибка не было, данные сами по себе были неверными, и пользователь должен вернуться, просмотреть свою электронную таблицу и исправить проблемы, выявленные свойством data в ответе «сбой».
Рассмотрение этого с точки зрения ошибок HTTP, хотя и является интересным упражнением, не всегда приводит к точному отображению (4xx = сбой, 5xx = ошибка). Это больше о том, что вы хотите сообщить клиенту: произошло что-то плохое, чего не должно было случиться («ошибка») или сервер работает нормально, но ваш данные не совсем соответствует стандартам («сбой»).
Наконец, решать только вам, хотите ли вы также использовать ошибки HTTP. Вы всегда можете ответить 200 и позволить JSend говорить. Но это немного другая (и несколько религиозная) дискуссия. :-)
Надеюсь, это поможет.
Я нахожу этот ответ сбивающим с толку: вы говорите: «Думая об этом с точки зрения ошибок HTTP, хотя это интересное упражнение, не всегда получается точное сопоставление (4xx = сбой, 5xx = ошибка)». В вашем примере вы отвечаете fail, когда есть проблема с электронной таблицей, и error, если, например, его нельзя сохранить на диск, даже если все в порядке. Разве это не 4xx: «Client_errors» против 5xx: «Server error»? У вас есть пример, где fail должен иметь код ошибки HTTP 5xx или где error должен быть 4xx?
Питер, ты прав. Где я борюсь (почти через год после того, как я написал это), так это со спецификацией JSend, которая делает fail «ориентированным на плохие данные», а ключ message не является ни обязательным, ни необязательным. Я могу представить себе запрос PUT с несоответствием отметок времени между клиентом и сервером (на основе заголовков HTTP и нет на данных клиента), в результате чего будет получен ответ 409 (конфликт). Ясно, что нет ничего плохого в самих данных и ответе JSend error с code 409 и message «Объект на сервере более свежий, чем данные запроса». вполне уместно.
По моему личному мнению, при использовании JSend для REST API основная проблема заключается в отказе JSend от заголовков HTTP как неотъемлемой части REST API. Поле status JSend является избыточным, поскольку эта информация уже содержится в HTTP-заголовке Status (они даже называются одинаково). «Спецификация должна быть настолько маленькой, ограниченной и универсальной, насколько это возможно. Как таковая, она должна быть в некоторой степени автономной». - Но REST должен охватывать заголовки и команды HTTP, а не делать вид, что их не существует.
Действительно. В наши дни я использую коды состояния HTTP и простой объект со свойством message при ошибке. Таким образом, нет проблем с axios или связанными библиотеками. JSend, кажется, пытается решить проблему, которой на самом деле никогда не было.
Я знаю, что это немного странно, но если вы так думаете, возможно, это будет понятно (если вы (клиент) не предоставите мне правильные данные, я дам вам (серверу) ошибку) Серверы всегда выдают ошибку, клиент всегда не в состоянии предоставить правильные данные. Право @FrankHellwig
@ Tarek.Eladly Именно так. Мне нравится твоя логика. Согласно такому мышлению, даже 404 технически является «неудачей» по сравнению с «ошибкой», поскольку клиент не смог предоставить действительный URL-адрес. Итак, да, вы (клиент) не смогли указать действительное местоположение. Прохладный.
Позже в нем говорится, что «рекомендуется, чтобы разработчики на стороне сервера использовали оба: предоставить тело ответа JSend и любой HTTP-заголовок (-ы), наиболее подходящий для соответствующего тела». ... так что, если вы считаете, что эти ошибки являются наиболее подходящими в этих ситуациях (и в целом я с вами согласен), то вперед.