Какой код Http я должен возвратить для “Вещи, не найденной”?
rx всегда будет ловить ошибку, даже если это RuntimeException. Таким образом, вы можете выбросить какое-то исключение Runtime в блоке catch. Вот как на самом деле это должно работать.
Observable.just(bitmap)
.map(b -> {
try {
// do some work which throws IOException
throw new IOException("something went wrong");
} catch (IOException e) {
throw new RXIOException(e);
// Or you can use
throw Exceptions.propagate(e);
// This helper method will wrap your exception with runtime one
}
}).subscribe(o -> {
// do something here
}, exception -> exception.printStackTrace());
public static class RXIOException extends RuntimeException {
public RXIOException(IOException throwable) {
super(throwable);
}
}
8 ответов
404 Not Found - правильный ответ, если это служба, она на самом деле используется не людьми, а машинами, и поэтому опечатки не должны быть вашей первой проблемой.
. Кроме того, вы в любом случае мало что сможете сделать, чтобы противостоять человеческому поведению (думать одно, а на самом деле другое). Если вы возвращаете небольшое сообщение об ошибке как часть кода ошибки, все должно работать. Вы даже можете предложить им возможное исправление.
Возврат 500, когда приложение делает именно то, для чего оно предназначено, также кажется немного странным. 404 точно описывает ситуацию: Ресурс не найден.
Я думаю, вам следует использовать 404. Разработчики API поймут, что означает 404, и поэтому последуют за ним. собственный обычный процесс отладки, чтобы решить проблему. Придерживайтесь протокола.
Разработчики API поймут, что означает ошибка 404, и, следовательно, будут следовать обычному процессу отладки для решения проблемы. Придерживайтесь протокола. Разработчики API поймут, что означает ошибка 404, и, следовательно, будут следовать обычному процессу отладки для решения проблемы. Придерживайтесь протокола.IMHO, ответ HTTP - это не подходящее место для обработки этого, поскольку ошибка не на уровне HTTP. Это на уровне приложения. Одно из возможных решений - использовать шаблон Null Object для возврата нулевого «Покровителя», который соответствует интерфейсу Patron, но указывает, что такого человека не существует.
ОБНОВЛЕНИЕ: Я был убежден, что это неправильный ответ. Однако я хочу оставить его, так как это потенциально действительный ответ (в зависимости от деталей, не представленных в вопросе), и я думаю, что комментарии поучительны.
Ошибка 404 на самом деле является более приемлемым ответом для этого случая, потому что ресурс действительно не найден. У вас всегда может быть собственный документ об ошибке, в котором объясняется, что не найден именно идентификатор патрона.
Ошибка 400 означает, что клиент отправил неверный синтаксис, что не относится к вашему примеру. Таким образом, вам не следует использовать этот код ошибки. Может показаться, что «неверный запрос» является точным, но на самом деле это означает ошибку в синтаксисе заголовка запроса.
Это также не ошибка 500, потому что ошибок не было. Нет проблем с тем, что веб-сервер выполняет запрос, дело в том, что запрос ищет ресурс, которого нет.
404 - единственный подходящий ответ, если вы не хотите считать его полностью действительным запросом, вернуть статус 200 и страницу, объясняющую, что запрошенный Патрон не существует.
Из моего первоначального комментария по вопросу:
Я не думаю, что ошибка 200-го уровня будет подходящей, рассмотрите объяснения в W3 w3.org/Protocols/rfc2616/rfc2616-sec10.html
Обычно, если ваша служба обнаруживает ошибку, которую не может обработать, но запрос сформирован правильно, я думаю, вы захотите вернуть код состояния 500.
Кроме того, еще одна причина, по которой я говорю, что 500 будет уместным, заключается в том, что из моего опыта работы с веб-службами .NET, всякий раз, когда я генерирую исключение по сети (например, исключение RecordNotFound), веб-сервер и клиент всегда интерпретируют ответ как 500 код состояния.
В любом случае было бы неплохо просмотреть этот список кодов состояния HTTP и выбрать тот, который лучше всего соответствует вашим потребностям.
Это зависит от того, какой тип веб-службы вы создаете.
Веб-службы SOAP и XML обычно возвращают 200 OK, если запрошенный объект (покровитель) не может быть найден, и кодируют тип ошибки / сообщение / description в ответный документ. Они отделяют транспортный уровень (HTTP) от передаваемых сообщений (XML). Ошибка 404 (которая находится на транспортном уровне) возвращается только в том случае, если вы запрашиваете несуществующую конечную точку API (неправильный URL-адрес).
Однако с веб-службой REST вы используете методы и статусы HTTP непосредственно для обмена сообщениями. REST использует разные методы HTTP (GET / POST / PUT / DELETE), чтобы указать, какое действие требуется, и сервер возвращает статус как статус HTTP. Таким образом, в случае веб-сервиса REST, 404 будет правильным статусом HTTP, если клиент не может быть найден.
500 в любом случае неуместен, я думаю,
Если вы хотите контролировать ответы веб-службы с помощью кодов ответов HTTP, вы действительно можете использовать 404 для обозначения этого условия.
Однако я думаю, что более естественно иметь ответ веб-службы полностью определяется в теле ответа HTTP и просто возвращает 200 для успешного взаимодействия («Я понял ваш запрос и отправил вам соответствующий ответ»). В этом случае вы вернете 200 как обычно с полезной нагрузкой вашего запроса (XML, JSON или что-то еще), указывая на то, что соответствующий объект не найден
Я бы рассмотрел коды ошибок, отличные от 200, аналогично исключениям в обычном программировании языков, а тело ответа HTTP больше похоже на код возврата. Представьте, если бы вы реализовали это условно - вы бы выбросили исключение, если не было найдено никакой сущности или вернуть null ? Лично, учитывая хрупкий характер сетевых подключений, я бы хотел зарезервировать все коды ошибок уровня HTTP для проблем со связью, и я бы предпочел всегда возвращать 200 OK из самой службы вместе с полезная нагрузка, указывающая результат или любую ошибку уровня обслуживания.
Ошибки на уровне веб-службы должны не просто возвращать простую строку состояния HTTP, но вместо этого должны возвращать контент в допустимом и задокументированном формате, который может быть проанализирован клиентом, обращающимся к вашей службе. Возвращенный документ должен содержать код ошибки, который является частью задокументированного набора кодов, специфичных для вашей веб-службы, а также краткое описание проблемы и, при необходимости, более подробное описание проблемы.