Как обрабатывать некорректные отформатированные запросы в API

Question

Мне интересно, как правильно обрабатывать запросы такого типа.У меня есть запросы на удаление из пользовательского интерфейса, и это список идентификаторов, которые являются целыми числами.Таким образом, запрос может выглядеть так:

www.myui.com/delete/1,2,3,4 

, который является хорошо отформатированным запросом.Но если запрос по какой-либо причине был получен из запроса curl или почтальона и т. Д., Он может быть отформатирован следующим образом:

www.myui.com/delete/1,,3,4 

В этом случае 2-й индекс будет содержать ноль, так как он проверяет целые числа.Однако, если бы мы ожидали список String, это была бы просто пустая строка или n символов пробела, если бы он был отформатирован как / 1, 2,3, 4, поэтому мне пришлось бы перебрать запрос и проверитьесли строка в списке строк является только пробелом и возвращает 404.

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

Ниже приведен пример того, как я в настоящее время обрабатываю запрос, который являетсяСписок целых чисел.

@DeleteMapping(value="/delete/{ids}")
    public ResponseEntity delete(@PathVariable("ids") List<Integer> ids)
            throws DatabaseException {
        if (ids.contains(null)) {
            return new ResponseEntity<>(HttpStatus.BAD_REQUEST);
        }
        service.delete(ids);
        return new ResponseEntity<>(HttpStatus.NO_CONTENT);
    }

Answer 1

Короче говоря, быстрый отказ - это лучший подход, поскольку он помогает выявлять неисправности очень рано и быстро, хотя вы можете также учитывать бизнес-требования и общие рекомендации по проектированию вашего приложения, если оно должно быть мягким, то вы можете пойти с чем-то вроде:

service.delete(ids.stream().filter(Objects::nonNull).collect(Collectors.toList()));

и вернуть тело ответа, содержащее как минимум несколько удаленных элементов.

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

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

Наконец, я надеюсь, что целочисленные идентификаторы в вашем случае не генерируются в БД, и в этом случае это будетбыть серьезной проблемой безопасности, так как вы подвергаетеЕсли вы используете API, злоумышленник может просто стереть вашу базу данных или ее части, просто отправив список инкрементных целых чисел.Я бы посоветовал вам использовать какие-то случайно сгенерированные уникальные идентификаторы для показа через API (это не означает, что вы должны избавиться от целочисленных базовых индексов).

Answer 2

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

Хотя ваш подход хорош, рассмотрение @ResponseHandler может быть поучительным, так как его можно использовать дляобобщить обработку известных исключений на уровне Controller.