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

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

НС>

НС>Нет в HTTP и API-специфичных вещей. Например, я обычно делаю заголовок X-Api-Warning стандартным в ответах (в значениях — коды, которые можно посмотреть в документации по конкретному сервису). Основной сценарий — извещать клиента о том, что его запросы перестают соответствовать требованиям и нужно бы что-то сделать. Например, появился новый API, на который нужно перейти.

НС>Re[26]: Идемпотентность POST — хорошая ли практика?

Автор: maxkar
Дата: 29.09.22

P>>>>Ты не в курсе, что такое делегирование и весь код у тебя в контроллерах? Чужой компонент может обрабатывать реквесты от твоего имени, все, что тебе надо — дать конфиг.
НС>>>Я не понимаю как это все касается темы обсуждения.
P>>Это еще пример, когда анализ changelog не поможет — надо смотреть зависимости второго уровня.

НС>Все равно непонятно.

Что тут непонятного? Компонент — часть твоего сервиса, и сам обрабатывает http-трафик, откуда ясно, что ничего пропагейтить не надо. Теперь одна из зависимостей этого компонента вдруг чего то там поменяла. Как ты это обнаружишь, если не собираешься читать changlelog зависимостей 2го уровня?

НС>Я не понимаю какое отношение к передаче чего то между сервисами имеют внутрисервисные компоненты. Разговаривали про коммуникацию между сервисами, логично было предположить что речь шла про зависимости между сервисами. И ту, внезапно, ты пишешь про какие то внутренние зависимости.

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

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

Потому, что это проще и дешевле. Нагрузка на транспорт ничтожная. А твое предложение — поднять, как вариант, редис, подразумевает, что и платить за этот редис и прочие сопутствующие вещи. "Такие вещи, как я уже сказал, обычно делаются при помощи CR и оператора (либо, если нужна супероперативность, с каким нибудь промежуточным хранилищем типа редиса или консула), "
Более того — запрос к редису всё равно придется делать. Т.е. вместо строчки варнинга, условно, 100 байт максимум, у тебя будет запрос в редис, как минимум. С т.з. разработки нам надо теперь протестировать, что наша апликачка не просто возвращает чего то там, а еще и правильно взаимодействует с редисом, и этот редис надо теперь таскать во все деплойменты.
Далее, редисом дело не ограничивается, это все надо по любому вывести в мониторинг.

Итого — если можно решить черз АПИ, стоит начать именно с этого.