Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>В топике зашла речь именно про него.
P>>Это просто пример кастомного хидера.

НС>Речь шла не про хидеры, а про "Нет в HTTP и API-специфичных вещей".

А можно ссылкой? Как я помню, товарищ упомянул слабую коммуникацию с консумером и способ это обойти

P>> Такие хидеры ни разу не рокетсаенс, и поддерживаются тем же ResponseHeaders в OpenApi

НС>При чем тут ResponseHeaders в OpenApi?

Как я вижу, вытут возбудились именно от кастомности хидера, основная претензия "а кто их читать будет"

P>>Ты не в курсе, что такое делегирование и весь код у тебя в контроллерах? Чужой компонент может обрабатывать реквесты от твоего имени, все, что тебе надо — дать конфиг.

НС>Я не понимаю как это все касается темы обсуждения.

Это еще пример, когда анализ changelog не поможет — надо смотреть зависимости второго уровня. Там часто прячутся просто чудовищные дыры или ломающие изменения.

P>>Про делегирование ты не в курсе. Как же ты чужой компонент контролируешь, ы?

НС>Зачем контролировать чужой компонент?

А он часть твоего сервиса, как я уже показал пример.

P>>Если это часть апи, то нужно ожидать, что мониторинг на той стороне справится самостоятельно.

НС>Зачем вообще нужен мониторинг на той стороне, если проще на этой?

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

НС>>>Не знаю при чем тут архитектура поверх всего и что ты под ней понимаешь. Но больше на эту роль подходят кастомные хидеры.
P>>Ты сам привел пример, забыл?

НС>Я окончательно перестал тебя понимать.

В твоих сообщенияз был пример, "как надо делать"

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>В топике зашла речь именно про него.
P>>Это просто пример кастомного хидера.

НС>Речь шла не про хидеры, а про "Нет в HTTP и API-специфичных вещей".

А можно ссылкой? Как я помню, товарищ упомянул слабую коммуникацию с консумером и способ это обойти

P>> Такие хидеры ни разу не рокетсаенс, и поддерживаются тем же ResponseHeaders в OpenApi

НС>При чем тут ResponseHeaders в OpenApi?

Как я вижу, вытут возбудились именно от кастомности хидера, основная претензия "а кто их читать будет", читай себя же http://rsdn.org/forum/design/8376379.1

Автор: Ночной Смотрящий
Дата: 04.10.22

P>>Ты не в курсе, что такое делегирование и весь код у тебя в контроллерах? Чужой компонент может обрабатывать реквесты от твоего имени, все, что тебе надо — дать конфиг.

НС>Я не понимаю как это все касается темы обсуждения.

Это еще пример, когда анализ changelog не поможет — надо смотреть зависимости второго уровня. Там часто прячутся просто чудовищные дыры или ломающие изменения.

P>>Про делегирование ты не в курсе. Как же ты чужой компонент контролируешь, ы?

НС>Зачем контролировать чужой компонент?

А он часть твоего сервиса, как я уже показал пример.

P>>Если это часть апи, то нужно ожидать, что мониторинг на той стороне справится самостоятельно.

НС>Зачем вообще нужен мониторинг на той стороне, если проще на этой?

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

НС>>>Не знаю при чем тут архитектура поверх всего и что ты под ней понимаешь. Но больше на эту роль подходят кастомные хидеры.
P>>Ты сам привел пример, забыл?

НС>Я окончательно перестал тебя понимать.

В твоих сообщенияз был пример, "как надо делать"