Использовать исключения Java для ошибок пользователя API REST?

Question

У нас есть REST API, который прекрасно работает. Мы проводим рефакторинг и решаем, как внутренне обрабатывать ошибки пользователями нашего API.

Например, пользователю необходимо указать параметр URL «movie», который должен принимать значение «1984», «Crash» или «Avatar». Сначала мы проверяем, имеет ли оно допустимое значение.

Что было бы лучшим подходом, если параметр фильма недействителен?

• вернуть ноль из одного из внутренних методов и проверить нулевое значение в основном методе вызова API
• выбросить исключение из внутреннего метода и перехватить исключения в основном методе API

Я думаю, это сделает наш код более читабельным и элегантным для использования исключений. Однако мы неохотно, потому что мы могли бы вызвать много исключений из-за ошибок ввода пользовательского API, наш код мог бы быть идеальным. Это не похоже на правильное использование исключений. Если существуют большие потери производительности с исключениями, которые имеют смысл при необходимости сбора трассировок стека и т. Д., Тогда мы излишне тратим ресурсы, когда все, что нам нужно сделать, - сообщить пользователю, что параметр неверен.

Это методы API REST, поэтому мы не распространяем исключения на пользователей API, и мы не хотим, даже если это возможно.

Так какая же здесь лучшая практика? Использовать уродливые нули или использовать механизм исключений Java?

Answer 1

Ни.

Ключ в том, что передача неверного параметра не является исключительным условием. Исключения создаются для исключительных обстоятельств. (Это причина не использовать их здесь, а не производительность.)

Вы должны использовать что-то вроде API DataValidation Spring для привязки передаваемых параметров.

Клиент API REST не должен получать значение NULL или исключения. Они должны получить сообщение об ошибке, которое дает им представление о том, что происходит, не раскрывая эти детали. "Извините, мы не смогли найти этот фильм" или ноль? Иди с первым, руки вниз.

Answer 2

Если поступил неверный запрос (например, ошибка проверки), вы должны показать код состояния 400 (неверный запрос).

Внутренне я бы также создал иерархию исключений, которая сопоставляется с доменом HTTP Rest (см. Коды состояния для случаев ошибок).

Примеры (упрощенные и непроверенные исключения):

class RESTBaseException extends RuntimeException{
  int statusCode;

  public RESTBaseException(int statusCode){ this.statusCode=statusCode; }

  //if no statusCode passed we fallback to very broad 500 server error.
  public RESTBaseException(){ this.statusCode=500; }  
}

class RESTValidationException extends RESTBaseException{

   RESTValidationException(){
      super(404);
   }
}

Вы можете расширить приведенные выше примеры, также передав сообщения об ошибках в конструктор, чтобы сделать клиента еще более счастливым.

Позже вы должны перехватить эти исключения с помощью специального обработчика исключений в цепочке обработчиков сервлета (сопоставление кода состояния с ответом сервлета). Например, весной mvc есть хорошие решения для обработки исключений для этого.

Обычно я не люблю создавать глубокие пользовательские иерархии исключений, но я думаю, что для уровней REST API они в порядке (потому что коды состояния распространяются позже).

Answer 3

Я предполагаю, что вы проводите проверку ввода здесь, и в этом случае ваша база данных выполнит запрос безопасной строки и не найдет запись, так как ее нет в вашей базе данных, хорошо? *

Если вы используете какую-либо инфраструктуру MVC, Модель должна уже выдать исключение RecordNotFound no?

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

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

Более важно: что вы делаете в других местах кода? Важна последовательность.