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

S>Ваше предложение "тупо отключить его нахрен и всё — тогда-то и посмотрим, кто прибежит жаловаться" встречает резкое непонимание со стороны вашего руководства: "Вам разве Меган не объясняла, сколько будет стоить отказ в обслуживании? Что значит не можете найти — найдите, разберитесь, и помогите им перейти на новую версию".
Ты невнимательно читаешь. Это ровно то, что происходит у Pauel: При траблшутинге они заинтересованы решать всё быстро тк они несут убыток, и все вопросы решаются буквально голосом..
Моё предложение: "Важно получить подверждение от всех клиентов, что они переписали свои приложения на новый API, успешно всё задеплоили и не собираются делать rollback."

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

·>А предложенная альтернатива какая? Посылать им хедеры?
Да, совершенно верно. В документации на сервис вы пишете про эти хедеры; в примерах клиентского кода к вашему API вы анализируете эти хедеры в тестовых методах; в клиентских биндингах на C#, Java, Python и Typescript вы прикручиваете интеграцию с лог-сервисами и метриками, в которые заливаете информацию про эти хедеры.
На звонках с разработчиками, которые пилят работу с вашим сервисом, вы объясняете, как важны хедеры с ворнингами — что вы начинаете троттлить тех, кто игнорирует много ворнингов, поэтому крайне желательно встраивать ассерты в интеграционные тесты на их стороне.
Поэтому когда Джон Доу в 2022 году сдаёт модуль интеграции с вами в службу эксплуатации Acme Inc и увольняется навсегда, на той стороне остаётся код, который в далёком 2030 году, когда нынешний API станет устаревшим, зажжот лампочку в дашборде Acme, inc.
И те же люди в Акме, которые звонят Сьюзан "поговори с этими орлами из точка-инк, у них медианный респонс тайм вылез за 700миллисекунд, что за ерунда???", заведут в ихней корпоративной жире (в которую вам, естественно, хода нет) тикет, и этот тикет будет блуждать по очередям и проектам, пока не попадёт к Бобу. Который, собственно, и починит проблему — причём когда он попробует собрать новую версию своего клиента, который ходит к вам, ему CI/CD не даст сделать коммит — интеграционные тесты в других местах API загорятся красненьким, потому что в каждом из них написано Assert.DoesNotContain("X-Api-Warning", response.Headers).

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

·>Моё предложение: "Важно получить подверждение от всех клиентов, что они переписали свои приложения на новый API, успешно всё задеплоили и не собираются делать rollback."
Погодите с подтверждением! Вы всё ещё не нашли почтовые адреса этих клиентов, чтобы их известить о новом API.

Как раз подтверждение на вашей стороне получить очень легко — просто смотрите в свои логи. Вот как только нету обращений к легаси API за какой-то период времени (например, месяц подряд) — ок, всё, можно тушить сервера.
И наоборот: есть в логах эти обращения — значит, гарантированно кто-то всё ещё пользуется API, не взирая на все предупреждения.
Это — гораздо надёжнее, чем любые письма от клиентов с любыми подтверждениями либо опровержениями.

Ситуация, когда клиент АПИ сам не знает, что он использует, а что — нет, — норма в нашем бизнесе.
Когда Microsoft внедрял новую схему авторизации в своём Partner Center API, то сначала они хотели просто отключить старую авторизацию через три месяцаа.
Через три месяца они поняли, что ничего не выйдет, и начали активно приглашать партнёров на звонки для обсуждения этой темы, где все партнёры согласно кивали головами "да-да, мы всё понимаем, мы работаем над этим" или даже "да мы давно уже всё перевели".
Ещё через три месяца они прикрутили в клиентский дашборд метрику "доля запросов, которая пользуется старой схемой авторизации".
Ещё через три месяца они доработали дашборд так, чтобы он показывал эту долю per application и per IP address — потому что партнёры в ужасе смотрели на вот эти "32%" и говорили "да мы уже ВЕЗДЕ посмотрели — всё заменено, всё суперновое, это какой-то глюк". Естественно, каждый раз находилась +1 команда на стороне партнёра, которая сидела себе там в башне, пряла шерсть, и знать не знала ни про какие запреты веретён. И пока их носом не ткнёшь: "вот, ваш же сервис нас тут долбит" — и выяснялось что-нибудь типа ежедневного отчёта, в который шесть лет назад прикрутили сбор данных через этот API. С тех пор отчёт давно изменили, данные PC API из него выкинули, но в датасет они по-прежнему собираются. О чём, естественно, не знает вообще никто из нынешних сотрудников.

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

мессагу всем L2 и попросить, что бы они разыскали каждый своё? Или нанять человека, кторый будет диспетчером работать?
·>Я предполагаю такой механизм уже должен существовать. Неужели у вас нет способа найти другую команду по request-id?
Ну если бы такой способ существовал — как бы он выглядел?
Как вы его себе представляете?

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

·>Я предполагаю такой механизм уже должен существовать. Неужели у вас нет способа найти другую команду по request-id?

У нас задача — емейл с request-id который надо отослать конкретной L2 команде. Расскажи, по шагам, как это всё будет работать от начала и до конца
Ты пока нигде подробно не показал это, только общие слова "емейл пошлём и всё"

P>>У нас хидер нужден для другого кейса — мы им сообщаем что у них проблема.
·>Почему тогда они прибегают с прода?

Вероятно, это ты сейчас пытаешься подменить тему. У нас кейс — мы уведомляем людей что у них есть некоторых проблемы на их стороне с их реквестами.

P>>Это минимальное условие, которое можно себе позволить.
·>Звучит невероятно.

Если это невероятно, то на емейлы полагаться вовсе не стоит — а ну как их зловред какой откажется форвардить или тикеты создавать?

P>>С email выходит еще хуже. Например, регулярно случается кейс "ой, шота рассылки перестали ходить"
·>chase&escalate. Ведь email это двухсторонний канал. А хедер — односторонний. В этом основная беда.

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

P>>Всё равно нужно искать ту самую команду, а уже потом внутри нее разбираться с произошедшим. То есть — два шага.
·>Ты ж вроде заявлял, что у вас есть трейсы. С 0го шага вбиваешь request-id и трейсишь до той самой команды. И сразу на 6-7 шаг — на адрес их L2 или AD шлёшь мыло-джиру-whatever.

До какой той? Твои трейсы работают в твоей сети. Их трейсы — в их сети. Максимум, что ты можешь получить — что реквест пришел через ваш api gateway или файрвол или лоадбалансер. Это и без трейса известно.
А надо по request-id который пришел тебе найти команду на той стороне. Расскажи подробно, что за механизм, и кто именно за это отвечает.

P>>Ровно то же, только рендерить будем не в хидер, а в энвелоп "диагностика: { варнинг: "<описание или ссылка или еще что>" }"
·>Ты так и не рассказал в энвелоп чего.

Зачем мне это? Ты уклоняешься показать свой вариант решения, но хочешь что бы я подробно рассказал тебе свое видение. Какой в этом смысл?

Здравствуйте, 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 не порезал неизвестные хедеры. Как правло тест на отсутствие чего либо — плохой тест, ненадёжный.

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

S>·>Моё предложение: "Важно получить подверждение от всех клиентов, что они переписали свои приложения на новый API, успешно всё задеплоили и не собираются делать rollback."
S>Погодите с подтверждением! Вы всё ещё не нашли почтовые адреса этих клиентов, чтобы их известить о новом API.
S>Как раз подтверждение на вашей стороне получить очень легко — просто смотрите в свои логи. Вот как только нету обращений к легаси API за какой-то период времени (например, месяц подряд) — ок, всё, можно тушить сервера.
S>И наоборот: есть в логах эти обращения — значит, гарантированно кто-то всё ещё пользуется API, не взирая на все предупреждения.
Верно. Но для этого, внезапно, и хедер не нужен. Нужны только наши логи.

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

S>Через три месяца они поняли, что ничего не выйдет, и начали активно приглашать партнёров на звонки для обсуждения этой темы, где все партнёры согласно кивали головами "да-да, мы всё понимаем, мы работаем над этим" или даже "да мы давно уже всё перевели".
S>Ещё через три месяца они прикрутили в клиентский дашборд метрику "доля запросов, которая пользуется старой схемой авторизации".
S>...
И они это сделали варниг-хедером? Какой из них warning header? И могу предположить, что дашборд хостился у самого майкрософта.

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

S>мессагу всем L2 и попросить, что бы они разыскали каждый своё? Или нанять человека, кторый будет диспетчером работать?
Или тулзу соорудить для трейсинга.
Это очень зависит от конкретной инфраструктуры. У кого к чему есть доступ. Если всё тривиально как у Pauel, можно заглядывать в их логи, то вообще проблем не вижу — заходишь в логи и грепаешь по request-id.

S>·>Я предполагаю такой механизм уже должен существовать. Неужели у вас нет способа найти другую команду по request-id?
S>Ну если бы такой способ существовал — как бы он выглядел?
S>Как вы его себе представляете?
Ну например, ты сам рассказал как в башне пряли шерсть. Нашли же? И без хедера. ЧТД.

Здравствуйте, ·, Вы писали:
·>Это очень зависит от конкретной инфраструктуры. У кого к чему есть доступ. Если всё тривиально как у Pauel, можно заглядывать в их логи, то вообще проблем не вижу — заходишь в логи и грепаешь по request-id.
Это никак не зависит от конкретной инфраструктуры. В "их логи" вы заглядывать не сможете, ни при каких условиях. Заглядывать будут условные "они".

S>>Как вы его себе представляете?
·>Ну например, ты сам рассказал как в башне пряли шерсть. Нашли же? И без хедера. ЧТД.
Угу. Это заняло примерно полтора года. У компании, у которых ресурсов примерно столько, сколько у РФ.
Байки на эту тему я могу рассказывать долгими зимними вечерами, не повторяясь, несколько лет подряд.

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

S>>И наоборот: есть в логах эти обращения — значит, гарантированно кто-то всё ещё пользуется API, не взирая на все предупреждения.
·>Верно. Но для этого, внезапно, и хедер не нужен. Нужны только наши логи.
Но без хедера в ваших логах всегда будут вызовы к старому API. И поддерживать его придётся и вам и вашим потомкам
·>Не надёжнее. Они могут решить откатиться, например.
Как откатились — так и накатятся. Старая версия тупо не пройдёт интеграционные тесты.

·>И они это сделали варниг-хедером? Какой из них warning header? И могу предположить, что дашборд хостился у самого майкрософта.
Нет, они пошли трудным путём. Если я плохо объяснил, то проговорю явно: это был отрицательный пример.

Здравствуйте, ·, Вы писали:
·>А в итоге доки не читают, всем плевать на логи, т.к. и так всё работает. Не будут городить огород и выкинут все эти "ненужные навороты, которые только всё замедляют и в коде мешаются".
Ну, тогда мы останемся наедине с вашим способом "давайте отправим письмо на несуществующий адрес".

·>Для троттлинга хедер посылать не надо.
И самого по себе его будет недостаточно, потому что всё, чего вы добъётесь — статьи на реддите "не пользуйтесь сервисом от точка-орг, у них пропускная способность два вызова в секунду".

·>В интеграционных тестах можно просто всё смело валить HTTP 400, насмерть роняя тест, а не скромно подсовывать хедер.
От вас опять ускользает простая мысль: интеграционные тесты гоняются на невашей стороне. С вашей стороны они неотличимы от прода, поэтому 400 означает просто отказ в обслуживании клиента.

·>Каком из дашбордов? И кто на этот дашборд смотрит? И реагирует ли на эти варнинги? С какой скоростью?
А это напрямую зависит от того, кто эксплуатирует ваш сервис. Если клиентам на него наплевать, то у них нет ни дашборда, ни метрик, ни логов, ни нужды в continuity. Начали вы им отдавать 400 — ну и хрен с ним, неважно.
Вот если у них mission critical application исполняется, то у них и дашборд, и мониторинг, и дежурный оператор на смене с телеграм-каналом, куда мониторинг валит события типа "сервис X начал плохо себя вести, надо бы разобраться". Задача, которую решает Pauel — дать таким ребятам механизм по построению таких дашбордов.

·>И какую же роль тут сыграл хедер? У клиента убытки, т.к. всё стало медленно работать, и вдруг наконец-то зачесались. Устроить проблемы у клиентов можно и без хедера.
Задача — перед устроением проблем устроить им ворнинги.

·>Повторюсь, что для ингеграционных тестов из _нашего_ сервиса можно просто возвращать 4xx.
Расскажите, как вы отличите интеграционные тесты, выполняемые на стороне клиента, от настоящей эксплуатации. А заодно расскажите, что именно будут тестировать интеграционные тесты на вашей стороне.

·>А не полагаться что _их_ тесты содержат нужный ассерт или какой-нибудь там новый WAF не порезал неизвестные хедеры.

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

S>·>Это очень зависит от конкретной инфраструктуры. У кого к чему есть доступ. Если всё тривиально как у Pauel, можно заглядывать в их логи, то вообще проблем не вижу — заходишь в логи и грепаешь по request-id.
S>Это никак не зависит от конкретной инфраструктуры. В "их логи" вы заглядывать не сможете, ни при каких условиях. Заглядывать будут условные "они".
И чем хедер поможет-то контролировать чужие логи?

S>>>Как вы его себе представляете?
S>·>Ну например, ты сам рассказал как в башне пряли шерсть. Нашли же? И без хедера. ЧТД.
S>Угу. Это заняло примерно полтора года. У компании, у которых ресурсов примерно столько, сколько у РФ.
Круто, но роль хедера не раскрыта.
...А вот был бы хедер, то они бы к обеду справились. Да?

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

S>>>И наоборот: есть в логах эти обращения — значит, гарантированно кто-то всё ещё пользуется API, не взирая на все предупреждения.
S>·>Верно. Но для этого, внезапно, и хедер не нужен. Нужны только наши логи.
S>Но без хедера в ваших логах всегда будут вызовы к старому API. И поддерживать его придётся и вам и вашим потомкам
И с хедером — тоже.

S>·>Не надёжнее. Они могут решить откатиться, например.
S>Как откатились — так и накатятся. Старая версия тупо не пройдёт интеграционные тесты.
Для этого не нужен хедер. Можно просто возвращать 404.

S>·>И они это сделали варниг-хедером? Какой из них warning header? И могу предположить, что дашборд хостился у самого майкрософта.
S>Нет, они пошли трудным путём. Если я плохо объяснил, то проговорю явно: это был отрицательный пример.
А положительный пример есть?

Здравствуйте, ·, Вы писали:
·>И чем хедер поможет-то контролировать чужие логи?
Тем, что он в них будет.
Давайте развернём задачу.

Представьте себя разработчиком какого-то сервиса внутри Акме инк. Ваша компания ежесекундно зависит от нескольких сотен внешних API — курсы валют, валидация адресов в 52 странах присутствия, прогнозы погоды, формирование пакетов для отправки потребителям, управление виртуальными машинами в облаке, етк, етк.
Ваша задача — не пропустить момент, когда кто-то из сотен вендоров этих API соберётся что-то у себя менять, вы своевременно об этом узнали.
Как вы это сделаете?



·>Круто, но роль хедера не раскрыта.
·>...А вот был бы хедер, то они бы к обеду справились. Да?
Нет, уложились бы в изначально запланированные три месяца.

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

·>Для этого не нужен хедер. Можно просто возвращать 404.
И все-все, кто не успел проапгрейдиться, просто встанут? Ну, хорошо, когда вы так можете. В реальности это работает только для нишевых компаний, которые обоих своих клиентов знают лично.
Такой опыт у меня тоже есть — когда я баги в вызовах нашего АПИ чинил рукожопым партнёрам сам, просто сказав "вы задолбали, пришлите мне архив с вашим кодом, я покажу как надо".
За что, кстати, был подвергнут порицанию, и справедливо

S>>Нет, они пошли трудным путём. Если я плохо объяснил, то проговорю явно: это был отрицательный пример.
·>А положительный пример есть?
Положительного примера с large-scale API — нету. Поэтому я с большим вниманием читаю эту ветку, где опытные коллеги, уже побегавшие по тем же граблям, предлагают более совершенные решения известной мне проблемы.

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

S>·>И чем хедер поможет-то контролировать чужие логи?
S>Тем, что он в них будет.
S>Давайте развернём задачу.
S>Представьте себя разработчиком какого-то сервиса внутри Акме инк. Ваша компания ежесекундно зависит от нескольких сотен внешних API — курсы валют, валидация адресов в 52 странах присутствия, прогнозы погоды, формирование пакетов для отправки потребителям, управление виртуальными машинами в облаке, етк, етк.
S>Ваша задача — не пропустить момент, когда кто-то из сотен вендоров этих API соберётся что-то у себя менять, вы своевременно об этом узнали.
S>Как вы это сделаете?
Повторюсь. Это административная задача, а не техническая. Хедером не решается.
Внезапно выяснится, что курсы валют у нас идут по multicast udp, где каждый бит на счету, и никаких хедеров да и вообще респонзов нет, а просто price stream.
Валидация адресов тебе по scp закачивают файлик, формат которого иногда немного меняется.
Пакеты отправляются раз в квартал и хедеры пришедшие два месяца назад никакого смысла уже не имеют.
Да и помимо тривиальных сообщений, что нечто deprecated, может быть множество других событий о работоспособности сервисов. Плановые отключения, смена настроек, сертификатов, и т.п. За всем надо следить.

Для каждого канала будет своя саппорт-команда с живыми людьми, которая скурпулёзно отслеживает все анонсы (по какому бы каналу они ни приходили). А шо делать? Какой-нибудь трейдинг использует сотню бирж по всему миру, и у каждой свой особенный протокол и особенности.

S>·>Круто, но роль хедера не раскрыта.
S>·>...А вот был бы хедер, то они бы к обеду справились. Да?
S>Нет, уложились бы в изначально запланированные три месяца.
Каким образом? Будет у тебя какой-нибудь REST-клиент в виде bash-скрипта с curl-ом. И пофиг на твой супер-хедер. Как ты блин заставишь _всех_ хотя бы тесты прогонять перед релизом? Даже майкрософту с их бюджетом это недоступно.

Т.е. конечно, хедер добавить можно. Но эффект будет прямо пропорционален сложности. В простых случаях он будет работать, но в простых случаях и без хедера просто. А в сложных случаях помогать не будет, только ложное чувство уверенности добавляет и API усложняет.

Так что вместо хедера можно просто в бубен ударять. Полезного эффекта будет ровно столько же.

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

·>Для каждого канала будет своя саппорт-команда с живыми людьми, которая скурпулёзно отслеживает все анонсы (по какому бы каналу они ни приходили).
Стоимость решения представляете себе?

·>Каким образом? Будет у тебя какой-нибудь REST-клиент в виде bash-скрипта с curl-ом. И пофиг на твой супер-хедер. Как ты блин заставишь _всех_ хотя бы тесты прогонять перед релизом? Даже майкрософту с их бюджетом это недоступно.
У вас почему-то выбор строго между баш-скриптом с курлом, и отдельной саппорт-командой, которая 24х7 отслеживает блоги разработчиков, телеграм каналы, и вообще всё подряд.
Хотелось бы построить что-то менее дорогое, чем персональная команда на каждый API, и более надёжное, чем баш-скрипт.

·>Т.е. конечно, хедер добавить можно. Но эффект будет прямо пропорционален сложности. В простых случаях он будет работать, но в простых случаях и без хедера просто. А в сложных случаях помогать не будет, только ложное чувство уверенностпи добавляет и API усложняет.
Ну, всё возможно. Практика — критерий истины. Если у коллеги Pauel такое решение есть и работает, то как минимум я бы его отметать не стал.
Особенно с учётом того, что предлагаемое вами решение я проверял, и оно меня не устраивает.

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

S>·>Для каждого канала будет своя саппорт-команда с живыми людьми, которая скурпулёзно отслеживает все анонсы (по какому бы каналу они ни приходили).
S>Стоимость решения представляете себе?
Других вариантов нет, если нужна надёжная система.
Хедер не поможет.

S>·>Каким образом? Будет у тебя какой-нибудь REST-клиент в виде bash-скрипта с curl-ом. И пофиг на твой супер-хедер. Как ты блин заставишь _всех_ хотя бы тесты прогонять перед релизом? Даже майкрософту с их бюджетом это недоступно.
S>У вас почему-то выбор строго между баш-скриптом с курлом, и отдельной саппорт-командой, которая 24х7 отслеживает блоги разработчиков, телеграм каналы, и вообще всё подряд.
S>Хотелось бы построить что-то менее дорогое, чем персональная команда на каждый API, и более надёжное, чем баш-скрипт.
Я не сказал, что для каждого API должна быть отдельная персональная команда. Я сказал, что за анонсами каждого API должна следить команда. Это может быть одна команда, которая следит за всеми API.
Например, на одной из прошлых работ у была Market Connectivity team. Которая отвечала за всю ~сотню бирж. И там не только deprecated api (куда кстати, хедер пихать в какой-нибудь FIX — неясно), но и всякие аннонсы изменений в opening hours, holidays, data centre relocations, изменения в требованиях аудита, routing rules, переключения между dr/prd и т.д., т.п.
Упихать всё в хедеры — я не представляю какой монстр получится.

S>·>Т.е. конечно, хедер добавить можно. Но эффект будет прямо пропорционален сложности. В простых случаях он будет работать, но в простых случаях и без хедера просто. А в сложных случаях помогать не будет, только ложное чувство уверенностпи добавляет и API усложняет.
S>Ну, всё возможно. Практика — критерий истины. Если у коллеги Pauel такое решение есть и работает, то как минимум я бы его отметать не стал.
Так не работает же. К нему с прода с убытками бегают, по его же словам.

S>Особенно с учётом того, что предлагаемое вами решение я проверял, и оно меня не устраивает.
Зато работает.

Здравствуйте, ·, Вы писали:
·>Других вариантов нет, если нужна надёжная система.
·>Хедер не поможет.
Ну, если его нет — то да, не поможет.
Непонятно, чем будет плохо, если он есть.

·>Я не сказал, что для каждого API должна быть отдельная персональная команда. Я сказал, что за анонсами каждого API должна следить команда.
Вы сказали, что на каждый канал — по одной команде.
Я это интерпретирую так, что за анонсами PC API Microsoft (публикуются на специальной страничке под авторизацией) следит одна команда.
За анонсами S3 API Amazon — другая команда. И так далее.

·>Это может быть одна команда, которая следит за всеми API.
·>Например, на одной из прошлых работ у была Market Connectivity team. Которая отвечала за всю ~сотню бирж. И там не только deprecated api (куда кстати, хедер пихать в какой-нибудь FIX — неясно), но и всякие аннонсы изменений в opening hours, holidays, data centre relocations, изменения в требованиях аудита, routing rules, переключения между dr/prd и т.д., т.п.
Интересно, сколько было народу в этой команде.
·>Упихать всё в хедеры — я не представляю какой монстр получится.
Всё, наверное, не упихаешь. Но вот если мы хотим ввести какое-то ужесточение в существующем API (а это бывает очень часто), или там планируем перенести этот API на другой адрес/в другой DC, то можем это легко проанонсить при помощи тех самых warning. Ну вот появилось у вас в версии 1.2 API поле "адрес получателя денег". Сначала оно optional, чтобы не сломать существующих клиентов. Но — c warning. Чтобы был повод забеспокоиться.
Народ начинает осваивать обязательность, и в версии 1.3 оно становится обязательным, и те, кто игнорировал warninigs, получают 4хх с соответствующим объектом ошибки.
Постепенно клиенты привыкают обращать внимание на warnings, потому что это выгоднее, чем их игнорировать.

S>>Особенно с учётом того, что предлагаемое вами решение я проверял, и оно меня не устраивает.
·>Зато работает.
Как по мне — так нет. Регулярные опоздания с внедрением изменений на 12-18 месяцев — плохой результат. Надо лучше.

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

S>·>Других вариантов нет, если нужна надёжная система.
S>·>Хедер не поможет.
S>Ну, если его нет — то да, не поможет.
S>Непонятно, чем будет плохо, если он есть.
Затем, что это дополнительная функциональность, которую надо проектировать, документировать, тестировать, мейнтейнить и т.п. Плюс риск чего-нибудь поломать. Заспамить нечаяно мониторинг у кого-нибудь, например.

S>·>Я не сказал, что для каждого API должна быть отдельная персональная команда. Я сказал, что за анонсами каждого API должна следить команда.
S>Вы сказали, что на каждый канал — по одной команде.
S>Я это интерпретирую так, что за анонсами PC API Microsoft (публикуются на специальной страничке под авторизацией) следит одна команда.
S>За анонсами S3 API Amazon — другая команда. И так далее.
Э, нет, конечно, да и зачем? Может я оговорился где-то, но не имел в виду такое.

S>·>Это может быть одна команда, которая следит за всеми API.
S>·>Например, на одной из прошлых работ у была Market Connectivity team. Которая отвечала за всю ~сотню бирж. И там не только deprecated api (куда кстати, хедер пихать в какой-нибудь FIX — неясно), но и всякие аннонсы изменений в opening hours, holidays, data centre relocations, изменения в требованиях аудита, routing rules, переключения между dr/prd и т.д., т.п.
S>Интересно, сколько было народу в этой команде.
Не помню, порядка 5 человек, вроде, в разных таймзонах чтобы. По сути работа не сложная, но нудная... разгребать письма, поддерживать актуальную инфу во всяких документах, да тикеты создавать; знать структуру бизнеса, кто куда как соединяется, етс.

S>·>Упихать всё в хедеры — я не представляю какой монстр получится.
S>Всё, наверное, не упихаешь. Но вот если мы хотим ввести какое-то ужесточение в существующем API (а это бывает очень часто), или там планируем перенести этот API на другой адрес/в другой DC, то можем это легко проанонсить при помощи тех самых warning. Ну вот появилось у вас в версии 1.2 API поле "адрес получателя денег". Сначала оно optional, чтобы не сломать существующих клиентов. Но — c warning. Чтобы был повод забеспокоиться.
S>Народ начинает осваивать обязательность, и в версии 1.3 оно становится обязательным, и те, кто игнорировал warninigs, получают 4хх с соответствующим объектом ошибки.
Так же можно "наказывать" тех, кто игнорирует емейлы. Вот только емейл будет один, а хедеров миллионы.

S>Постепенно клиенты привыкают обращать внимание на warnings, потому что это выгоднее, чем их игнорировать.
Возможно это и сработает в каких-то случаях, но как универсальное решение ну никак не годится. Так я и представил как в каждое из десятка миллиона сообщений в день вдруг мы запихнём какой-то хедер и заспамим логи и мониторинг.

S>>>Особенно с учётом того, что предлагаемое вами решение я проверял, и оно меня не устраивает.
S>·>Зато работает.
S>Как по мне — так нет. Регулярные опоздания с внедрением изменений на 12-18 месяцев — плохой результат. Надо лучше.
Так 12-18мес не потому что хедера не было, а потому что люди должны что-то делать. Как десяток тысяч людей заставить что-то сделать быстрее с помощью хедера — не очень понимаю.