Должны ли все ответы об ошибках HTTP иметь одинаковую структуру JSON? - PullRequest
Новая
       16

Должны ли все ответы об ошибках HTTP иметь одинаковую структуру JSON?

1 голос
/ 21 июня 2019

Мы разрабатываем службу REST с помощью Spring Boot, и мы застревали, задаваясь вопросом, должна ли каждая реакция на ошибку иметь одинаковую структуру JSON?

В случае ошибок наша служба отвечает простым форматом JSON.Например, если параметр имеет неправильный формат, мы отвечаем с HTTP-статусом 400 и JSON: 

{
  "errorCode": 05,
  "message": "provided paramter XY is malformed"
}

errorCode - это идентификатор нашего пользовательского кода.Кто-то может поспорить, хорош этот дизайн или нет, но он прост и легко может быть обработан потребителем сервиса.

Теперь Spring Boot автоматически создает некоторые сообщения об ошибках.Например, для TypeMismatchException и ответа с HTTP-статусом создается 400.Но, конечно, эти автоматически сгенерированные ответы не имеют формата ошибки.

Итак ... у нас есть ситуация, когда потребитель службы предварительно не знает для статуса HTTP 400, имеет ли он простоеОшибка в формате JSON в теле или нет.Должны ли мы действительно перезаписывать всю обработку исключений Spring Boot по умолчанию, чтобы включить наш формат в каждый ответ, или потребитель службы должен проглотить горькую таблетку и определить, используется простой формат JSON или нет?

1 Ответ

0 голосов
/ 21 июня 2019

Зависит от масштаба вашего проекта. Если ваш API используется многими приложениями, вы должны пойти по пути «поймать все и использовать формат JSON». Да, у вас было бы больше дел, но когда любое другое приложение в вашей компании может использовать ваш стандартный способ, они могут сэкономить много времени.

В большинстве проектов, в которых я принимал участие, у нас также был «стандартный способ» возврата наших сообщений об ошибках (также JSON): 

@RestControllerAdvice
public class GlobalResourceExceptionHandler {

    private static final Logger LOGGER = LoggerFactory.getLogger(GlobalResourceExceptionHandler.class);

    // the class ValidationError contains the properties the json should contain.
    @ExceptionHandler(Exception.class)
    public List<ValidationError> exceptionHandler(Exception e, HttpServletResponse response) {
        LOGGER.warn("Exception thrown in a resource", e);
        response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
        return Collections.singletonList(new ValidationError(null, "unexpected exception"));
    }
}

Вы можете расширить класс еще @ExceptionHandler с.

Оказалось, что это довольно хороший способ, потому что он прост в реализации (также для небольших приложений) и охватывает много вопросов. Много значит в основном все, что связано с запросом отдыха. Из этого был исключен обработчик ресурсов, который предоставил приложение angular и уровень безопасности.

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

...