Здравствуйте, Sinclair, Вы писали:

S>·>А предложенная альтернатива какая? Посылать им хедеры?
S>Да, совершенно верно. В документации на сервис вы пишете про эти хедеры; в примерах клиентского кода к вашему API вы анализируете эти хедеры в тестовых методах; в клиентских биндингах на C#, Java, Python и Typescript вы прикручиваете интеграцию с лог-сервисами и метриками, в которые заливаете информацию про эти хедеры.
А в итоге доки не читают, всем плевать на логи, т.к. и так всё работает. Не будут городить огород и выкинут все эти "ненужные навороты, которые только всё замедляют и в коде мешаются".

S>На звонках с разработчиками, которые пилят работу с вашим сервисом, вы объясняете, как важны хедеры с ворнингами — что вы начинаете троттлить тех, кто игнорирует много ворнингов,
Для троттлинга хедер посылать не надо.

S>поэтому крайне желательно встраивать ассерты в интеграционные тесты на их стороне.
В интеграционных тестах можно просто всё смело валить HTTP 400, насмерть роняя тест, а не скромно подсовывать хедер.

S>Поэтому когда Джон Доу в 2022 году сдаёт модуль интеграции с вами в службу эксплуатации Acme Inc и увольняется навсегда, на той стороне остаётся код, который в далёком 2030 году, когда нынешний API станет устаревшим, зажжот лампочку в дашборде Acme, inc.
Каком из дашбордов? И кто на этот дашборд смотрит? И реагирует ли на эти варнинги? С какой скоростью?

S>И те же люди в Акме, которые звонят Сьюзан "поговори с этими орлами из точка-инк, у них медианный респонс тайм вылез за 700миллисекунд, что за ерунда???",
И какую же роль тут сыграл хедер? У клиента убытки, т.к. всё стало медленно работать, и вдруг наконец-то зачесались. Устроить проблемы у клиентов можно и без хедера.

S>заведут в ихней корпоративной жире (в которую вам, естественно, хода нет) тикет, и этот тикет будет блуждать по очередям и проектам, пока не попадёт к Бобу. Который, собственно, и починит проблему — причём когда он попробует собрать новую версию своего клиента, который ходит к вам, ему CI/CD не даст сделать коммит — интеграционные тесты в других местах API загорятся красненьким, потому что в каждом из них написано Assert.DoesNotContain("X-Api-Warning", response.Headers).
Повторюсь, что для ингеграционных тестов из _нашего_ сервиса можно просто возвращать 4xx. А не полагаться что _их_ тесты содержат нужный ассерт или какой-нибудь там новый WAF не порезал неизвестные хедеры. Как правло тест на отсутствие чего либо — плохой тест, ненадёжный.