Создание общего объекта ошибки, указывающего на частичный успех извлечения данных в Spring Boot

Question

Мой вопрос должен быть довольно простым.

У меня есть API-интерфейс Spring Boot REST.

@GetMapping("/customer")
public Customer getCustomer() {
    return service.getCustomer()
}

Мой контроллер возвращает List<Customer> и работает хорошо.Но теперь я хочу вернуть еще один объект с ошибками, которые могут возникнуть при сборе клиентов.Допустим, он называется GenericErrorClass

Итак, чтобы вернуть это, мне нужно создать класс, который группирует List и GenericErrorClass и возвращает этот класс, верно?

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

Как создать собственный объект без создания классов и вернуть его как json изконтроллер покоя?

Answer 1

Обычно вы возвращаете информацию об ошибке, если запрос не выполнен, что совпадает с кодом ошибки 4 / 5xx.Обычно в Spring вы управляете этой ситуацией с помощью обработчиков исключений, как показано здесь , где вы можете определить другое тело ответа.Есть и другая хорошая практика: используйте конверты для управления всеми ответами, я покажу вам пример

{
   status: 200,
   message: 'user retreieved',
   result:
   [
      {foo1:"bar1"},
      .....
   ]
}

ИЛИ

    {
   status: 400,
   message: 'bad request',
   error:
   {
     reason : "wrong field xxx in request"
   }
}

, чтобы клиенты могли обрабатывать запрос и предоставлять полезныеИнформация для пользователей.Для этого вам нужно определить класс, который используется для всех ответов и должен инкапсулировать результат или ошибку

Answer 2

Сначала вы должны знать, что уже существует аналогичный класс org.springframework.http.ResponseEntity, объект которого вы можете вернуть в ответ на ваш API.Он может обернуть тело вашего ответа - Список, Аккаунт, Продукт и т. Д. С возможностью переопределения статуса Http по умолчанию.

Итак, на основе этого примера вы можете написать свой собственный простой класс-обертку, например:

public class Response<T>
{
  private GenericErrorClass error;
  private T body;

  // constructors + getters + setters
}

и когда ваш метод API должен вернуть List<Customer>, вы вернете Response<List<Customer>>, точно так же, как другие объекты.

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

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

Answer 3

Не делайте этого.
Бросьте свое исключение или дайте ему сбежать из стека вызовов.Вместо этого используйте @ControllerAdvice (или @RestControllerAdvice) с @ExceptionHandler.

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

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