Каков наилучший способ обработки ответа 204 Нет содержимого в NestJS? - PullRequest
Новая
       11

Каков наилучший способ обработки ответа 204 Нет содержимого в NestJS?

0 голосов
/ 03 января 2019

Я пишу RESTful API в Nest, который я недавно начал использовать и люблю до сих пор.Однако я изо всех сил пытаюсь найти чистый шаблон для обработки ответов «Нет содержимого» для моих маршрутов GET.Любые рекомендации?

Я немного удивлен, что в платформе нет чего-то, что возвращало бы 204, если объект, возвращаемый методом контроллера GET, пуст - если есть, я его не нашелеще.Если это действительно не так, мне также интересно, стоит ли это запрос функции на GitHub.

Я пробовал следующее:

  • Предоставление свойства Express res с помощью@Response() в качестве параметра метода Controller, затем используйте res.sendStatus(204), если ответ пуст.Однако для этого требуется, чтобы я тоже вручную отправлял 200 ответов, в то время как я хотел бы по-прежнему полагаться на платформу для обработки цикла запрос-ответ и для поддержания методов моего контроллера как можно более чистыми.
  • Изучил использованиеперехватчик для проверки, является ли объект ответа пустым, затем записывает код состояния 204 в ответ.Я не хочу этого делать, потому что код состояния может измениться позже из-за фильтра исключений.
  • Использование промежуточного программного обеспечения для написания кода ответа, но мое промежуточное программное обеспечение выполняется до того, как оно направляется на контроллер, и мне нужночтобы проверить, пуст ли ответ после этого.res.on ('send') тоже не перехватывал ответ при выходе.
  • Создание пользовательского NoContentException для моего фильтра исключений для обработки.Хотя странно выдавать исключение для успешного кода ответа, я думаю, что именно так я и продолжу, поскольку мой фильтр исключений - это последнее, что будет выполняться в написанном мною коде.

1 Ответ

0 голосов
/ 03 января 2019

К сожалению, пока это невозможно. В документах написано:

Часто ваш код состояния не является статичным, но зависит от различных факторов. В этом случае вы можете использовать специфичный для библиотеки ответ (ввести с помощью @Res()) объект (или, в случае ошибки, выбросить исключение).

Вы также не можете просто установить код ответа в Interceptor, не отправив его (вместо sendStatus), потому что, как сказал Камиль в этом потоке :

логика контроллера глобального ответа - последний выполненный шаг перед отправкой окончательного результата через сеть (это место где приходят коды состояния по умолчанию).

Так что, если вы (по понятным причинам) не хотите использовать @Res в каждом контроллере, ExceptionFilter кажется лучшим вариантом, хотя и не совсем правильно.

Так как другие люди, похоже, имеют точно такую ​​же проблему , запрос функции может быть хорошей идеей. :-)

...